6V0-22.25 Planning and Designing

Planning and Designing Detailed Explanation

1. Requirements Gathering

Before deploying VMware Avi Load Balancer, you must collect detailed information about the application environment, traffic behavior, and security needs. This helps ensure your design is scalable, efficient, and aligned with business goals.

1.1 Application Requirements

Start by understanding what the application needs in order to be delivered properly through Avi.

Protocol Requirements
Identify the network protocols used by the application:

• HTTP / HTTPS – Web applications

• TCP – Databases, email services

• UDP – DNS, voice services, streaming media

• WebSocket – Real-time communication

• gRPC – Microservices communication

Session Persistence Needs
Determine if users should consistently connect to the same backend server:

• Source IP persistence

• Cookie-based persistence

• No persistence (stateless applications)

SSL/TLS Handling
Understand how the application handles secure traffic:

• SSL Offload – Avi decrypts HTTPS and forwards traffic as plain HTTP

• SSL Passthrough – Avi does not decrypt traffic

• SSL Re-encryption – Avi decrypts, inspects, and re-encrypts traffic before sending it to the backend

Performance Expectations
Clarify expected performance metrics:

• Latency requirements (e.g., <100ms)

• Expected number of concurrent users or CPS (Connections Per Second)

• Throughput requirements (data per second)

These influence how you design Service Engines and Virtual Services.

1.2 Traffic Characteristics

Once application needs are clear, you must assess traffic volume and patterns.

Average and Peak CPS
Determine average and maximum expected CPS. This metric directly impacts how many SEs you need and how powerful they must be.

Bandwidth Requirements
Estimate total incoming and outgoing data per second. This affects SE throughput planning and licensing (especially if throughput-based licensing is used).

Transaction Sizes
Understand if your application uses:

• Small packets (e.g., chat messages, API calls)

• Large files (e.g., media, documents)

This helps in tuning TCP buffers, compression, and caching settings.

Burst Traffic Behavior
Analyze how traffic behaves over time:

• Steady traffic?

• Sudden spikes (e.g., product launches, holidays)?

• Daily or weekly usage patterns?

Knowing this helps you decide whether to configure auto-scaling or reserve additional capacity.

1.3 Security Requirements

Security design must be addressed up front to avoid costly reconfiguration later.

SSL Inspection and Decryption
Determine whether HTTPS traffic should be decrypted:

• Required for WAF, analytics, or custom header inspection

• Requires managing SSL certificates and keys in the Avi Controller

• May impact CPU usage on SEs

Web Application Firewall (WAF)
Check if the app must be protected against OWASP Top 10 threats:

• SQL Injection, Cross-site scripting, etc.

• WAF can be enabled per Virtual Service

• Requires tuning to reduce false positives

Multi-Tenancy and Isolation
For environments with multiple business units or customers:

• Use Avi’s Tenants to logically separate configurations

• Each tenant gets its own VS, Pools, analytics, and certificates

• Prevent cross-tenant visibility and configuration access

Role-Based Access Control (RBAC)
Define user roles and assign permissions:

• Read-only users: View logs and configs

• Operators: Restart services, monitor health

• Admins: Full access to configure and manage resources

RBAC supports security best practices and audit readiness.

2. Capacity Planning

Capacity planning ensures your Avi Load Balancer deployment can handle current workloads and scale as traffic increases. This includes planning for both the Controller cluster and Service Engines (SEs).

2.1 Controller Sizing

The Avi Controller is the central control plane that manages configurations, policies, SE deployment, and telemetry data. It is critical to ensure it is sized correctly.

Cluster Design

• Always deploy Controllers as a 3-node cluster for high availability.

• They operate in an active-active mode for control tasks.

• The cluster uses quorum-based decision-making.

CPU and Memory Requirements

• Controller resource needs grow with:

  • Number of Virtual Services (VS)

  • Number of Service Engines (SEs)

  • Frequency and size of analytics data

As a general rule:

• Start with at least 8 vCPUs and 24 GB RAM per node in medium environments.

• Increase resources for large-scale deployments with hundreds of VSs.

Placement Best Practices

• Do not place all Controllers and SEs in the same failure domain (e.g., same rack or availability zone).

• This ensures fault tolerance in case of localized hardware or network failures.

2.2 Service Engine (SE) Sizing

Service Engines do the actual work of handling client traffic, performing load balancing, SSL termination, content switching, and more.

CPU and Memory Requirements

• Each SE is deployed as a VM or container.

• The required vCPUs and RAM depend on:

  • Number of concurrent client connections

  • Whether SSL is offloaded (SSL consumes CPU)

  • Number of Virtual Services hosted on the SE

A few examples:

• Small SE: 2 vCPUs, 4 GB RAM (light traffic)

• Medium SE: 4 vCPUs, 8 GB RAM (moderate traffic)

• Large SE: 8+ vCPUs, 16+ GB RAM (high throughput, SSL)

Headroom Planning

• Always plan for extra capacity to allow for:

  • Sudden traffic spikes

  • Maintenance (e.g., taking one SE offline)

  • Auto-scaling events

Avoid resource starvation by ensuring host infrastructure has enough CPU/memory available for SEs to expand when needed.

2.3 Scale-Out Design

Avi supports horizontal scaling, which means you can add more SEs to handle increased load. The system also supports elastic scaling.

Horizontal Scaling with SE Groups

• SEs are grouped into Service Engine Groups (SE Groups).

• Each group can scale independently.

• Virtual Services are assigned to SE Groups.

Auto-Scaling Triggers
You can configure scaling policies based on:

• CPU utilization

• Memory usage

• Network throughput (Mbps or packets per second)

• Connections per second (CPS)

Elastic HA (N+M) Design

• Instead of statically assigning backups, use N+M redundancy:

  • N = number of active SEs needed

  • M = number of spare SEs

• Ensures availability without overprovisioning

• Efficient and cost-effective for large or unpredictable workloads

3. High Availability (HA) Design

High availability (HA) ensures your application delivery continues without interruption, even when a failure occurs in hardware, software, or the network. In Avi, HA is achieved through redundancy in both the control plane (Controllers) and data plane (Service Engines).

3.1 Controller HA

The Avi Controller cluster is the brain of the system, so its high availability is critical.

3-Node Cluster Design

• Always deploy three Controller nodes for full HA.

• These nodes form a quorum-based cluster:

  • A majority (at least 2 of 3) must be online to make decisions.

Active-Active Control Plane

• All three Controllers are active simultaneously for handling:

  • Configuration changes

  • Analytics collection

  • Monitoring

• If one node fails, the remaining two continue operations seamlessly.

Availability Zones

• Place each Controller node in a separate fault domain:

  • Different racks

  • Different data centers or cloud availability zones

• This avoids single points of failure in power, networking, or storage.

3.2 Service Engine (SE) HA Models

Service Engines process live traffic, so HA for SEs ensures no user impact if a VM or host fails.

Avi supports multiple SE HA models, and you can choose per use case.

Active/Standby

• One primary SE handles all traffic.

• One secondary SE is on standby, ready to take over.

• Instant failover when the primary fails.

• Used for stateful Virtual Services or low concurrency needs.

Pros: Fast failover, resource-efficient for low-scale apps
Cons: Standby SE is unused until failover, wasting resources in some cases

Active/Active

• Multiple SEs handle traffic concurrently.

• Load is balanced across all SEs in the group.

• If one fails, traffic is redistributed to remaining SEs.

Pros: Better performance and resource utilization
Cons: Not ideal for all applications (some may require sticky sessions)

Elastic HA (N+M Redundancy)

• Deploy N active SEs (to handle current load)

• Add M standby SEs (shared across many VSs)

• Avi will dynamically assign standby SEs when needed.

This model provides:

• High resilience

• Efficient use of resources

• Automatic scaling and failover

Example:

• 10 SEs needed for regular traffic (N = 10)

• Add 2 spares (M = 2)

• If any of the 10 fail, the 2 spares can take over

3.3 Fault Domains

A fault domain is a group of infrastructure components (hosts, racks, zones) that could fail together.

Design Principles

• Distribute Controllers and SEs across at least two fault domains

• Avoid placing both active and standby SEs on the same host or rack

• In cloud: use Availability Zones (AZs) to isolate components

This ensures the system remains available during:

• Rack failures

• Host crashes

• Power outages

• Network segmentation

Summary: High Availability Design

Component	HA Strategy
Controller	3-node quorum cluster, active-active control, separate fault domains
SE: Active/Standby	One active, one standby per VS – instant failover, simpler design
SE: Active/Active	Shared traffic across multiple SEs, better performance and scalability
SE: Elastic HA	N active + M standby SEs for dynamic failover and scaling
Fault Domain Design	Distribute across racks, hosts, or AZs to prevent shared points of failure

4. Multi-Tenancy and Segmentation

Multi-tenancy allows you to logically divide your Avi Load Balancer environment into isolated sections. This is essential for supporting multiple teams, business units, environments, or customers on the same Avi platform without overlap or interference.

4.1 Tenants

A tenant in Avi is a logical container that isolates configuration, analytics, and operational data.

Key Concepts:

• Each tenant has its own:

  • Virtual Services

  • Pools

  • SSL certificates

  • Health monitors

  • Analytics data

• Tenants can be:

  • Departments (e.g., HR, Finance, Engineering)

  • Environments (e.g., Dev, Test, Prod)

  • Clients (in a service provider model)

Benefits:

• Logical separation

• Independent management per tenant

• No visibility into other tenants’ data

Best Practices:

• Use separate Service Engine Groups per tenant when traffic or performance isolation is required

• Create naming conventions for easier organization

4.2 Role-Based Access Control (RBAC)

RBAC enables user access control based on their role and associated privileges.

Common Roles:

• Read-Only: Can view configurations and analytics, but cannot make changes

• Operator: Can perform actions like restarting services or applying policies

• Tenant Admin: Full control within a specific tenant, but not system-wide

• System Admin: Full control over all tenants and system settings

How It Works:

• Users are assigned roles

• Roles define permissions

• Users can be scoped to specific tenants

RBAC Design Tips:

• Use LDAP or Active Directory integration for user authentication

• Keep least-privilege principle in mind

• Use custom roles for fine-grained control

4.3 Cloud Configuration Segmentation

Avi can manage resources in multiple environments (called clouds), such as:

• vCenter-based private cloud

• AWS

• Azure

• OpenStack

Each cloud can be assigned:

• To specific tenants

• With its own authentication, image templates, and networking rules

Cloud Isolation Use Cases:

• Dev tenant uses vCenter Cloud A

• Prod tenant uses AWS Cloud B

• Tenants cannot see or control each other’s infrastructure

Scoping Access:

• Users can be restricted to:

  • Specific tenants

  • Specific clouds

  • Specific roles in each cloud

This allows full flexibility in hybrid or multi-cloud environments, while maintaining strict isolation and access control.

Summary: Multi-Tenancy and Segmentation

Feature	Purpose
Tenants	Logical separation of apps, teams, or clients
RBAC	Fine-grained user access control based on roles and responsibilities
Cloud Configuration	Isolate and scope cloud environments by tenant
Security and Governance	Prevent misconfiguration and maintain compliance

5. Networking and Routing Design

Networking design in Avi Load Balancer affects performance, reachability, scalability, and high availability. It is essential to carefully plan Service Engine placement, VIP management, and routing behavior.

5.1 Service Engine (SE) Placement

Service Engines process live traffic, so they must be deployed strategically close to backend applications.

Key Guidelines:

• Low Latency: Place SEs in the same data center, region, or cloud availability zone as the applications they serve.

• Proximity: Avoid routing traffic through long, unnecessary network paths.

• Avoid Bottlenecks: Distribute SEs to avoid network chokepoints or shared resource contention.

Deployment Modes:

• One-Arm Mode:

  • SEs use a single interface for both client and server-side communication.

  • Simplifies routing and VLAN configuration.

  • Useful in small or simple environments.

• Two-Arm Mode:

  • SEs have separate interfaces for client-side and server-side networks.

  • Offers better isolation and control.

  • Preferred in enterprise environments with strict segmentation.

5.2 VIP Allocation

A Virtual IP (VIP) is the IP address clients connect to when accessing applications through Avi.

Planning VIPs:

• Pre-allocate IP ranges for VIPs based on application tiers, environments, or tenants.

• Choose between:

  • Static IP Assignment: Manual configuration of VIPs.

  • Dynamic IPAM: Avi integrates with IP Address Management (IPAM) systems to automatically assign VIPs.

External vs Internal VIPs:

• External VIPs: Used for internet-facing services (public DNS, secured via firewall/NAT).

• Internal VIPs: Used within the data center or VPC (for east-west traffic).

Best Practices:

• Reserve enough VIPs for future growth.

• Use separate subnets for different environments (e.g., dev, test, prod).

• Use DNS to map friendly names to VIPs.

5.3 Route Advertisements

Route advertisements allow Avi to inform upstream routers about where to find VIPs.

Supported Protocols:

• BGP (Border Gateway Protocol)

• OSPF (Open Shortest Path First)

When a new VIP is created or moved between SEs, Avi can dynamically update the routing tables of the network.

Benefits of Dynamic Routing:

• Fast failover (if an SE fails, the VIP is advertised from another SE)

• Efficient path selection

• No need for manual route configuration

ECMP (Equal-Cost Multi-Path Routing):

• Avi supports ECMP to distribute traffic across multiple SEs that advertise the same VIP.

• Enhances performance and reliability.

• Must be supported by upstream routers and switches.

Policy-Based Routing (PBR):

• You can define routing behavior based on:

  • Source IP

  • Destination port

  • Application type

• Useful for multi-tenant environments or service segmentation.

Summary: Networking and Routing Design

Component	Key Considerations
SE Placement	Deploy near backend apps, choose one-arm or two-arm mode based on needs
VIP Allocation	Use IPAM or pre-allocated pools, plan for internal and external services
Route Advertising	Use BGP or OSPF for dynamic updates, enable ECMP for load sharing
PBR	Customize routing per application or tenant

6. Security and Compliance Design

Security and compliance are foundational aspects of any enterprise-grade load balancing architecture. VMware Avi Load Balancer includes features for SSL/TLS management, Web Application Firewall (WAF), isolation, and access control — all of which need to be planned properly during design.

6.1 SSL Management

Centralized and secure SSL handling is essential for protecting data and simplifying administration.

Centralized Certificate Management

• Avi Controller centrally manages:

  • SSL certificates

  • Certificate chains

  • Private keys

• You can import certificates manually or automate via:

  • APIs

  • ACME (e.g., Let’s Encrypt)

  • Integration with enterprise PKI

Key Design Points:

• Plan certificate lifecycles, expiration alerts, and renewal workflows

• Use secure key storage and access restrictions

• Automate renewal and deployment wherever possible

SNI (Server Name Indication) Support

• Multiple domains can share one Virtual Service (VS) using SNI

• Example: one VIP hosts:

  • www.example.com

  • api.example.com

  • app.example.com

Each domain can use a different SSL certificate

6.2 WAF Placement

Avi’s built-in Web Application Firewall (WAF) helps protect applications from Layer 7 attacks.

OWASP Protection

• Defends against OWASP Top 10 threats, including:

  • SQL injection

  • Cross-site scripting (XSS)

  • Command injection

• Uses ModSecurity engine with customizable rules

Design Considerations:

• Enable WAF per Virtual Service as needed (not globally)

• Start in Detection Mode to monitor traffic without blocking

• Transition to Blocking Mode once confident in rule tuning

• Adjust signatures to reduce false positives

Performance Impact

• WAF introduces some processing overhead

• Consider enabling only on services that require strict security

6.3 Segmentation and Isolation

Strong segmentation ensures compliance and limits the blast radius of potential breaches.

Service Engine Group Isolation

• Assign different SE Groups for:

  • Each tenant

  • Different application types (e.g., internet-facing vs internal)

• SE Groups can use different:

  • Networks

  • Security policies

  • Scaling thresholds

Network-Level Isolation

• Use separate VLANs or subnets for:

  • Front-end (client-facing) traffic

  • Back-end (app/server-facing) traffic

• Apply firewall rules between:

  • SEs and backend servers

  • Tenants

  • Zones or regions

Compliance-Oriented Design

• Align isolation with standards like:

  • PCI-DSS (finance)

  • HIPAA (healthcare)

  • GDPR (data privacy)

• Maintain audit logs, enforce RBAC, and ensure traffic encryption

Summary: Security and Compliance Design

Component	Key Planning Considerations
SSL Management	Centralized cert storage, SNI for multi-domain TLS, secure key handling
WAF	Enable per VS, begin in detection mode, tune rules to reduce false positives
Isolation	Use SE Group and network separation for app and tenant segmentation
Compliance Support	Meet industry requirements with logging, access control, and encrypted traffic

7. Integration Planning

In modern environments, integration with automation, monitoring, and cloud platforms is essential for agility, observability, and scalability. This section covers how Avi fits into broader enterprise and DevOps ecosystems.

7.1 Automation and DevOps

Avi is built with a REST API-first approach, making it easy to automate every aspect of configuration and operation.

Infrastructure-as-Code (IaC) Integration:

• Terraform:

  • Use Terraform providers to define Avi objects (e.g., Virtual Services, Pools, SE Groups) as code

  • Enables repeatable, version-controlled deployments

• Ansible:

  • Automate tasks such as:

    • Creating/deleting Virtual Services

    • Modifying pools or SSL settings

  • Use Avi’s Ansible collection for full control

• vRealize Automation (vRA):

  • Allow self-service provisioning of applications with integrated load balancing

  • Useful for internal platforms or private cloud portals

CI/CD Integration:

• Trigger Avi configuration changes from tools like:

  • Jenkins

  • GitLab CI/CD

  • GitHub Actions

Design Tips:

• Keep automation templates modular and reusable

• Use tagging and naming standards

• Manage sensitive data (e.g., certificates, credentials) securely

7.2 Logging and Monitoring

Visibility into application and infrastructure performance is critical for operations, security, and compliance.

Log Streaming:

• Avi can send logs to external platforms in real time:

  • Syslog

  • Kafka

  • Elasticsearch

  • Splunk

Logs include:

• Client connection details

• Application performance data

• Security events (WAF, SSL errors)

• System activity and audit logs

Metric Collection:

• Avi provides detailed telemetry:

  • Per Virtual Service, per Pool, per backend server

  • Latency, errors, throughput, SSL handshake times

• Export metrics to:

  • Prometheus

  • Grafana

  • vRealize Operations

Dashboards:

• Use built-in UI or external tools to build custom dashboards:

  • For application teams (per-application health)

  • For operations (SE resource usage, alerts)

7.3 Cloud Provider Integration

Avi can be deployed across multiple cloud providers and integrates with each platform’s native features.

Supported Clouds:

• vCenter (private cloud): Full integration with VMware ecosystem (NSX-T, DRS, vMotion)

• AWS: Uses EC2, Elastic IPs, and IAM

• Azure: Supports NSGs, Load Balancer, and VM scale sets

• Google Cloud Platform (GCP)

• OpenStack

Cloud Configuration Planning:

• Each cloud is defined as a Cloud Object in Avi

• You can assign clouds to:

  • Specific tenants

  • Specific SE Groups

• Each cloud has its own:

  • Authentication method

  • Image templates

  • Networking and IPAM configuration

Design Considerations:

• Plan separate clouds for dev/test/prod

• Use cloud-native networking and security wherever possible

• Monitor cloud-specific resource limits (e.g., max interfaces per VM)

Summary: Integration Planning

Integration Area	Design Focus
Automation & DevOps	Use Terraform, Ansible, and vRA for provisioning and config-as-code
CI/CD Pipelines	Enable dynamic VS creation/config updates in app release workflows
Logging & Monitoring	Stream logs to ELK, Splunk, etc.; expose metrics to Prometheus/Grafana
Cloud Providers	Define clouds per platform; assign per tenant or use case; enable native integration

8. Application Delivery Design

Application delivery in Avi Load Balancer revolves around a few core concepts:

• Virtual Services (VS): The front-end IP and port that clients connect to

• Pools: Groups of backend servers that receive traffic from the VS

• Policies and Scripts: Advanced customization of traffic handling

8.1 Application Mapping

This step involves translating application architecture into load balancing components.

Virtual Services (VS):

• A VS represents a service exposed to clients

• It includes:

  • VIP (Virtual IP)

  • Port (e.g., 80, 443)

  • Protocol (HTTP, HTTPS, TCP, UDP)

  • SSL Profile (if HTTPS)

  • Load balancing policies

• Each application usually maps to one or more VS instances

Pools:

• A Pool is a collection of backend servers

• Each VS is associated with one or more Pools

• You can configure:

  • Load balancing algorithms (Round Robin, Least Connections, etc.)

  • Health monitors

  • Connection limits

  • Persistence profiles

Multi-Domain Hosting (SNI):

• Use SNI-based Virtual Services to host multiple domains on one VIP:

  • www.site1.com

  • www.site2.com

• Each SNI domain can:

  • Use a different SSL certificate

  • Point to different backend pools

Design Considerations:

• Use consistent naming for Pools and VSs

• Separate internal and external services

• Group services by tenant or application type

8.2 Custom Rules with DataScripts

Avi allows advanced customization through DataScripts, which are Lua-based scripts executed at runtime.

Use Cases:

• Header manipulation (add, remove, or rewrite headers)

• Custom logging

• Conditional redirects

• Blocking or allowing traffic based on logic (IP, URI, time, etc.)

• Traffic shaping or filtering

Example Scenarios:

• Add a security header to all HTTP responses

• Redirect mobile users to a different domain

• Drop requests from a specific country or IP range

Best Practices:

• Test scripts in staging before deploying in production

• Use logging to validate script behavior

• Keep scripts readable and modular

8.3 Health Monitors

Health Monitors actively or passively check the health of backend servers to ensure only healthy ones receive traffic.

Types of Health Monitors:

• ICMP (Ping)

• TCP (Check open ports)

• HTTP/HTTPS (Send a request and expect a response)

• DNS

• LDAP

• Custom External Scripts

Key Configurations:

• Frequency (how often to check)

• Timeout (how long to wait)

• Successful/failed thresholds (number of tries before marking a server up/down)

• Custom request/response strings (e.g., expect “200 OK”)

Best Practices:

• Customize per application

• Use appropriate health monitor types (e.g., HTTP for web, TCP for DB)

• Avoid aggressive frequency unless required

Summary: Application Delivery Design

Component	Key Points
Virtual Services	Represent front-end service endpoint; can use SNI for multi-domain setups
Pools	Define backend server groups and load balancing behavior
DataScripts	Add custom logic for advanced traffic control and inspection
Health Monitors	Continuously verify backend server health to ensure availability

Planning and Designing (Additional Content)

1. Business Requirement Mapping & Prioritization

Turning business goals into effective load balancer architecture requires structured requirement analysis.

Key Considerations:

• Performance Goals:

  • Define latency, throughput, QPS (queries per second), and failover RTO/RPO.

  • Choose SE sizing and quantity accordingly (e.g., dedicated SEs for high-throughput apps).

• Scalability Requirements:

  • Elastic HA model, auto-scaling policies, SE group placement in multi-cloud.

  • Account for future growth: avoid static provisioning.

• Security and Compliance:

  • TLS offloading, WAF profiles, audit logging, RBAC, and integration with corporate IDPs (LDAP, SAML).

  • Enforce network isolation by tenant, restrict API access.

• Cost Constraints:

  • Decide on deployment model (on-prem vs. cloud).

  • Map traffic throughput and SE cores to licensing tier.

Prioritization Framework:

Use a weighted decision matrix to score tradeoffs across:

• Cost vs. Performance

• Agility vs. Control

• Scalability vs. Operational complexity

Example:
If the business goal is rapid cloud adoption with limited CapEx, prioritize automation and public cloud SEs over deploying in private DCs.

2. Migration Strategy from Legacy Load Balancers

Transitioning from traditional appliances (F5, Citrix) to Avi must be carefully planned.

Migration Steps:

1. Inventory and Assessment:

   • Catalog all Virtual Servers, Pools, SSL certs, WAF rules, and iRules.

   • Identify deprecated or redundant services.

2. Design Mapping:

   • Convert legacy LB features (VIPs, persistence, SSL profiles) to Avi equivalents.

   • Address gaps such as unsupported features or differing configurations.

3. Migration Execution Models:

   • Lift and Shift: Quick, like-for-like migration of services.

   • Phased Rollout: App-by-app cutover, with coexistence and testing.

4. Rollback Strategy:

   • Always retain the ability to return to legacy LB (e.g., dual DNS entries, NAT routing).

   • Use DNS TTL to control traffic switchover.

5. Risk Mitigation:

   • Mirror traffic to Avi in parallel.

   • Use Avi’s FlightPath and metrics to validate behavior before cutting over.

   • Leverage test tenants or non-production zones for dry-runs.

3. Cost Modeling and Licensing Impact in Design Phase

Avi licensing models can influence architecture. Design decisions must reflect usage forecasts and licensing tiers.

Licensing Models:

• Throughput-Based: Charges based on aggregate inbound/outbound bandwidth.

• Per-SE vCPU: Each SE’s vCPU count contributes to total entitlement.

• Per-App (Per VS): Suitable for microservices or service-provider models.

Design Impacts:

• High QPS, small-size transactions → Favor vCPU model.

• Large file transfers (e.g., video apps) → Favor Throughput model.

• High VS count with many tenants → Per-App licensing is more predictable.

TCO Modeling:

• Include:

  • Hardware/VM resources for SEs and Controllers

  • Cloud IaaS cost (if deploying SEs in public cloud)

  • Operational cost (support, automation tools)

  • License cost (bandwidth or CPU-based)

Deployment Model Comparison:

Factor	On-Prem	Cloud
CapEx	High (HW, hypervisors)	Low
Opex	Lower (once deployed)	Higher (IaaS ongoing)
Elasticity	Limited	Native scaling
DR	Manual or high cost	Easier with cloud-native SE groups

4. Failure Scenarios & Recovery Design

Designing for fault tolerance is critical for exam scenario questions and production resilience.

SE Failure:

• SE HA models: Active/Active, Active/Standby, Elastic N+M.

• Failure triggers automatic traffic redistribution.

• Auto-replacement: If enabled, new SEs are spun up automatically.

Controller Failure:

• 3-node cluster recommended (quorum required).

• SEs continue forwarding traffic even if Controllers are all down.

• Management, analytics, and configuration changes will pause.

Regional or Network Failures:

• Design GSLB for regional traffic distribution.

• Use multi-region Controllers with separate SE Groups per region.

• Implement traffic steering policies (latency-based, geo-based).

Disaster Recovery (DR) Patterns:

• Active-Passive DCs: One site active, other on hot standby.

• Active-Active GSLB: Both DCs serve traffic with failover routing.

• Use shared configuration backup, replication of analytics if needed.

5. Operational Lifecycle Design Considerations

Avi design must account for long-term manageability.

Monitoring and Observability:

• Integrate with SNMP, Syslog, Prometheus, ELK, Grafana.

• Set alert thresholds per tenant, per VS (e.g., CPU > 80%, health score < 60).

• Define Analytics Profiles to tailor data granularity.

Capacity Planning:

• Plan for:

  • Number of Virtual Services

  • Expected peak QPS

  • TLS session rates

  • Multi-tenant growth

• Use historical metrics + forecasted trends.

Certificate Management:

• Use SSL Profiles per VS or tenant.

• Plan for certificate rotation policy, expiration alerts.

• Automate via API or external vaults (e.g., HashiCorp).

Upgrade Strategy:

• Use rolling upgrades (Controller → SE).

• Validate image compatibility, disk space, and automation scripts.

• Schedule maintenance windows, drain traffic with Maintenance Mode.

Lifecycle Management Tasks:

• Periodic clean-up of:

  • Old logs and analytics data

  • Unused VS/SE objects

  • Expired certs and profiles

6. Design Review and Validation Process

Every Avi deployment must undergo structured design review before going live.

Review Checklist:

• Tenant mapping validated

• SE Group placement and limits defined

• Licensing model aligned with expected usage

• RBAC and audit logging configured

• Integration with monitoring and CI/CD pipeline tested

Validation Techniques:

• Performance Testing:

  • Simulate expected traffic volume using synthetic test tools (e.g., Apache JMeter)

  • Validate QPS, latency, CPU usage under load

• Pre-Go-Live Checklist:

  • Backup config

  • Confirm NTP, DNS, SMTP reachability

  • Validate alerting and analytics dashboards

  • Run FlightPath traces and error simulation

Documentation and Audit Support:

• Architecture diagram

• Design decisions log

• API schema documentation (Swagger/OpenAPI)

• Change control log and rollback plans

Summary: Planning & Designing Essentials

Area	Key Focus
Requirement Mapping	Align business goals with technical solutions
Migration Strategy	Structured F5/Citrix to Avi cutover with rollback
Licensing Impact	Choose model based on traffic pattern and cost model
Failure Recovery	Build resilient SE/Controller architectures
Lifecycle Planning	Prepare for upgrades, monitoring, capacity, certs
Validation Process	Use checklists, tests, and documentation