3V0-22.25 IT Architectures, Technologies, Standards

IT Architectures, Technologies, Standards Detailed Explanation

1. Enterprise IT Architecture Basics

1.1 Business–IT Alignment

1.1.1 How business goals influence architecture decisions

Business goals determine the technical shape of an IT solution. Typical goals include:

• Availability
  High availability requirements (e.g., 99.99% uptime) lead to designs using clusters, redundancy, failover mechanisms, and multi-site protection.

• Compliance
  Regulatory or organizational compliance requirements drive the adoption of encryption, auditing, identity controls, segmentation, and standardized configurations.

• Scalability
  Expected workload growth influences cluster sizing, scale-out designs, modular architecture, and flexible storage/network expansion.

• Cost efficiency
  Budget constraints affect hardware selection, licensing models, lifecycle refresh cycles, feature adoption, and automation investment.

1.1.2 Mapping business needs to non-functional requirements

Common non-functional attributes include:

• Availability – percentage of uptime the system must provide.

• Performance – latency and throughput requirements.

• Security – authentication, authorization, encryption, segmentation.

• Manageability – ease of monitoring, automation, upgrades, lifecycle operations.

• Recoverability – acceptable RPO/RTO values, backup and DR strategies.

Each business goal becomes a technical requirement that shapes VMware platform design decisions (cluster layout, storage policies, network architecture, security configuration).

1.2 Logical vs Physical Architecture

1.2.1 Conceptual architecture

• High-level abstraction of system capabilities.

• Focuses on major domains such as compute, storage, networking, security, management.

• Does not specify products, versions, or hardware.

1.2.2 Logical architecture

• Describes IT components and their relationships without referring to hardware details.

• Includes application tiers, logical networks, security zones, workload domains, and service groupings.

• In VMware context, logical diagrams might show workload domains, clusters, NSX segments, or storage policies.

1.2.3 Physical architecture

• Represents real-world components such as server models, switch types, storage arrays, power, rack layout, and cabling.

• Includes ESXi host hardware, NICs, disk groups, uplink connections, firewall placements, and datacenter facilities.

1.3 Multi-tier / N-tier Architectures

1.3.1 Common tiers in enterprise applications

• Web tier – handles incoming HTTP/HTTPS traffic.

• Application tier – executes business logic.

• Database tier – stores persistent data.

Additional tiers may include caching, message queueing, analytics, or integration services.

1.3.2 Mapping tiers to VMware virtualization environments

• Each tier typically runs on its own VM group, resource pool, cluster, or namespace.

• NSX provides network segmentation to isolate tiers: Web → App → DB.

• Scaling uses additional VMs or container replicas depending on the architecture.

1.4 Monolithic vs Distributed / Microservices Architectures

1.4.1 Monolithic applications

• A single large application package.

• Typically deployed to one or a few large VMs.

• Scaling relies on “scale-up” (adding more CPU/RAM to VMs).

• VMware considerations: large-NUMA-aligned VMs, HA/DRS capacity reservations, snapshot/backup sensitivity.

1.4.2 Distributed / microservices applications

• Application logic split into many small services.

• Frequently deployed on Kubernetes as containers.

• Scaling relies on “scale-out” (adding more service replicas).

• VMware considerations: cluster density, pod-to-VM mappings, network policies, log/metric aggregation.

2. Datacenter and Cloud Models

2.1 On-Premises Datacenter

2.1.1 Characteristics

• Organization owns or controls the facility and hardware.

• Complete control over compute, storage, networking, security, and lifecycle.

• VMware platforms (vSphere, vSAN, NSX, VCF) are fully administered internally.

2.1.2 Responsibilities

• Hardware procurement and refresh cycles.

• Rack/power/cooling planning.

• Capacity forecasting, patching, upgrades, monitoring.

2.2 Cloud Service Models

2.2.1 IaaS (Infrastructure as a Service)

• Provides VMs, virtual networks, and storage.

• Internal vSphere/VCF is effectively an IaaS offering to internal users.

• Users manage OS and applications.

2.2.2 PaaS (Platform as a Service)

• Provides higher-level platforms such as Kubernetes clusters or Tanzu services.

• Users deploy applications without managing the underlying virtual infrastructure.

2.2.3 SaaS (Software as a Service)

• Fully managed applications (e.g., ITSM platforms, monitoring tools).

• No responsibility for infrastructure or platform layers.

2.3 Deployment Models

2.3.1 Private cloud

• Cloud functionality delivered within an on-premises environment.

• VCF is a primary technology for building enterprise private clouds.

2.3.2 Public cloud

• Compute/storage/network resources delivered by a cloud provider.

• VMware Cloud offerings extend vSphere into public cloud environments.

2.3.3 Hybrid cloud

• Combination of on-premises and public cloud platforms.

• Requires consistent networking, identity, and lifecycle management.

2.3.4 Multi-cloud

• Use of multiple public clouds plus potentially on-prem resources.

• Requires centralized governance, consistent policies, and cross-cloud operational visibility.

3. Core Virtualization Technologies

3.1 Compute Virtualization

3.1.1 Hypervisor fundamentals

A hypervisor is software that allows multiple virtual machines (VMs) to run on a single physical host.
VMware ESXi is a Type-1 hypervisor, meaning it runs directly on hardware (bare metal) without an underlying OS.

Key responsibilities of the hypervisor include:

• CPU scheduling

  • Determines which VM gets CPU time at any moment.

  • Uses time slicing and fairness algorithms to share physical CPUs among vCPUs.

• Memory management

  • Allocates, reclaims, and optimizes memory usage via techniques like transparent page sharing (TPS), ballooning, and swapping.

• Isolation

  • Ensures one VM cannot interfere with another in terms of CPU, memory, or security.

• Hardware abstraction

  • Provides standard virtual hardware to VMs (virtual NICs, virtual disks, virtual CPUs).

3.1.2 vCPU vs pCPU and overcommitment

• pCPU (physical CPU): a hardware CPU core.

• vCPU (virtual CPU): a virtualized CPU core presented to a VM.

VMware allows vCPU overcommit, meaning you can assign more vCPUs across all VMs than you have physical CPU cores.

Example:

• Host has 32 pCPUs.

• You deploy VMs totaling 64 vCPUs.

• Overcommit ratio = 64 / 32 = 2:1

Benefits:

• Higher utilization, cost efficiency.

Risks:

• CPU contention during peak workloads → performance degradation.

• VMs may experience CPU Ready time (waiting to run).

Overcommit must be done cautiously in production environments.

3.1.3 NUMA awareness and vNUMA

NUMA = Non-Uniform Memory Access

• Modern servers have multiple CPU sockets, each with its own memory.

• Memory access within the same NUMA node is faster than access across nodes.

VMware provides:

• NUMA scheduling: tries to keep a VM's memory/CPU within one NUMA node.

• vNUMA: exposes virtual NUMA topology to large VMs (typically >8 vCPUs).

Implications:

• Large VMs must be carefully sized to avoid spanning NUMA nodes inefficiently.

• Avoid allocating a VM more vCPUs than available on a single NUMA node unless necessary.

3.1.4 Memory reservation, ballooning, and swapping

Memory reservation

• Guarantees a VM a minimum amount of physical RAM.

• Useful for critical workloads.

Ballooning

• A VMware technique where the guest OS “returns” memory to the hypervisor through a balloon driver when ESXi is under pressure.

• Non-critical workloads may lose memory temporarily.

Swapping

• Last resort when memory is exhausted.

• ESXi writes VM memory pages to disk → very slow → severe performance impact.

Proper capacity planning minimizes ballooning/swapping.

3.2 Storage Virtualization

3.2.1 Storage types: block, file, and object

• Block storage

  • Provides raw block devices.

  • Used by VMFS datastores (SAN, vSAN).

• File storage

  • Provides file-level access.

  • NFS datastores use file protocols.

• Object storage

  • Stores data as objects with metadata.

  • Used in cloud-native environments, but not typically for VM datastores.

Understanding these helps determine which VMware storage technologies are suitable for which workloads.

3.2.2 SAN, NAS, DAS, and vSAN basics

• SAN (Storage Area Network)

  • Block storage over Fibre Channel (FC) or iSCSI.

  • Centralized, high performance, often expensive.

• NAS (Network Attached Storage)

  • File storage over IP networks using NFS/SMB.

  • Simple to deploy; good for file-heavy workloads.

• DAS (Direct Attached Storage)

  • Storage connected directly to a server.

  • Not shared; rarely used for VMware clusters.

• vSAN (VMware vSphere Storage Area Network)

  • Distributed storage built into ESXi.

  • Combines local disks of ESXi hosts into a shared datastore.

  • Enables cluster-wide storage without external SAN/NAS.

3.2.3 Storage performance concepts

• IOPS (Input/Output Operations Per Second)
  Higher IOPS → better for transactional systems.

• Throughput (MB/s)
  Important for large file transfers.

• Latency (ms)
  Measures response time; lower is better.

• Queue depth
  Determines how many I/O requests can be pending.
  A full queue → high latency → poor performance.

3.2.4 Provisioning and data efficiency

• Thin provisioning

  • Allocates space on demand.

  • Saves capacity but requires monitoring.

• Thick provisioning

  • Allocates full capacity immediately.

  • More predictable performance.

• Deduplication & compression

  • Reduce storage usage by removing duplicate data and reducing data size.

• Erasure coding

  • RAID-5/6–like storage efficiency in vSAN.

  • Better space savings than RAID-1 but higher CPU overhead.

3.3 Network Virtualization

3.3.1 L2 vs L3 networking, VLANs, trunks, MTU, routing, VRFs

• Layer 2 (L2): Switch-level communication; uses MAC addresses.

• Layer 3 (L3): Routing across networks; uses IP addresses.

VLANs

• Segment networks logically.

• Provide isolation between workloads.

Trunk ports

• Carry multiple VLANs across a single physical connection.

MTU (Maximum Transmission Unit)

• Packet size limit.

• vSAN, vMotion, and overlay networks often benefit from jumbo frames (MTU 9000).

Routing

• Controls traffic between subnets.

VRF (Virtual Routing and Forwarding)

• Allows multiple routing tables on the same router/switch.

• Improves segmentation and multi-tenant designs.

3.3.2 Overlay networks vs underlay networks

• Underlay

  • The physical network infrastructure.

  • Must be simple, stable, and high bandwidth.

• Overlay

  • Virtual networks built on top of the underlay.

  • Encapsulate traffic (VXLAN in older NSX-V; GENEVE in NSX-T).

Overlay benefits:

• Rapid network provisioning.

• Multi-tenant isolation.

• Security policies close to workloads.

3.3.3 VDS, NSX logical networking, T1/T0 gateways, distributed firewall

VDS (vSphere Distributed Switch)

• Provides consistent network configuration across hosts.

• Centralized management.

NSX Logical Networks

• Segments: L2 broadcast domains for VMs/pods.

• T1 Gateways: Tier-1 logical routers connecting segments.

• T0 Gateways: Tier-0 routers providing north–south connectivity.

Distributed Firewall (DFW)

• Enforces micro-segmentation at the vNIC level.

• Policies follow VMs wherever they migrate.

3.4 Storage and Network Quality of Service (QoS)

3.4.1 Resource allocation and enforcement

QoS ensures fair resource use among VMs:

• IOPS limits
  Prevent a single VM from dominating storage.

• Bandwidth limits
  Applied per vNIC or port group.

• Shares and reservations
  Prioritize critical workloads.

3.4.2 Noisy-neighbor prevention

A “noisy neighbor” is a workload that consumes excessive resources and harms other workloads.

Techniques to mitigate:

• Apply limits on aggressive VMs.

• Use shares to ensure priority.

• Separate workloads into different datastores, networks, or clusters.

• Monitor regularly and adjust policies.

4. Cloud-Native / Modern Application Technologies

4.1 Containers & Kubernetes

4.1.1 Basic Kubernetes components

• Pods
  Smallest deployable unit; runs one or more containers.

• Deployments
  Desired state definition for a set of pods; handles scaling and updates.

• Services
  Stable access points (cluster IP, load balancer) for pods.

• Ingress
  Provides external HTTP/HTTPS access to services.

• Namespaces
  Logical grouping; used for segregation and resource control.

4.1.2 Persistent storage concepts

• PersistentVolume (PV)
  Actual storage resource.

• PersistentVolumeClaim (PVC)
  App’s request for storage.

On vSphere:

• StorageClass maps to datastore/VMDK/vSAN policies.

4.1.3 How Kubernetes consumes VMware resources

Two main patterns:

• VM-based clusters
  Kubernetes nodes run as VMs on ESXi.

• Supervisor clusters (vSphere with Tanzu)
  Kubernetes is integrated natively into ESXi via a control plane.
  Pods can run directly on ESXi hosts (vSphere Pods).

4.2 Tanzu / VMware Kubernetes Integrations

4.2.1 Supervisor cluster

• Built-in Kubernetes control plane within vSphere.

• Uses NSX or VDS for networking.

• Enables namespaces for governance.

4.2.2 Workload clusters / Tanzu Kubernetes Grid

• User clusters created via the supervisor cluster.

• Developers deploy apps to these clusters.

4.2.3 Visibility in vSphere

• Pods/containers appear in vSphere inventory.

• Metrics/logs integrate with monitoring tools.

4.3 CI/CD & automation

4.3.1 Pipelines for infrastructure and applications

• CI/CD automates building, testing, deployment.

• IaC tools (Terraform, Ansible) create VMware resources automatically.

4.3.2 Integration with VMware APIs

• vSphere REST API

• vCenter API

• NSX API

• VCF API

Automation enables:

• Standardization

• Repeatability

• Reduced human error

5. IT Standards, Frameworks, and Compliance

5.1 Security Standards

5.1.1 CIS Benchmarks

• Hardening guidelines for vSphere, ESXi, and other systems.

• Define secure configuration states.

5.1.2 NIST frameworks

• Provide risk management and security controls.

• Often used by government or regulated industries.

5.1.3 ISO 27001 controls

• International standard for information security management.

• Influences logging, access control, encryption choices.

5.2 Compliance Regimes

5.2.1 Common regulations

• GDPR – data protection for EU residents.

• HIPAA – healthcare data security.

• PCI-DSS – payment card industry security.

• SOX – financial reporting controls.

5.2.2 Technical requirements these drive

• Encryption (at rest, in transit).

• Logging and audit trails.

• Segregation of duties.

• Secure access policies.

5.3 Operational Frameworks

5.3.1 ITIL concepts

• Incident management – restore service quickly.

• Problem management – identify root causes.

• Change management – controlled updates and maintenance.

5.3.2 Capacity, availability, continuity

• Ensuring sufficient resources.

• Designing for uptime.

• Planning for disaster recovery.

5.3.3 VCF and ITSM tool integration

• VCF events feed into ITSM (e.g., ServiceNow).

• Change workflows align with cluster upgrades or NSX/vSAN changes.

5.4 Architecture Frameworks

5.4.1 TOGAF-style thinking

• Uses layers, viewpoints, and building blocks.

• Helps structure enterprise architecture decisions.

5.4.2 VMware reference architectures

• Provide validated designs for vSphere, vSAN, NSX, VCF.

• Ensure compatibility, stability, and performance.

5.5 Standards for Interoperability

5.5.1 Hardware Compatibility (HCL/VCG)

• Ensures servers, NICs, storage controllers, and drivers are certified for ESXi/vSAN.

• Prevents instability or unsupported configurations.

5.5.2 Common IT standards

• SNMP – monitoring.

• Syslog – centralized logging.

• OpenAPI/REST – automation.

• OAuth/OIDC, SAML – identity federation.

IT Architectures, Technologies, Standards (Additional Content)

1. VMware Cloud Foundation (VCF) Architecture Fundamentals

VCF provides a standardized, validated architecture that integrates compute, storage, networking, and lifecycle management into a unified cloud platform. It eliminates design drift and enables consistent private-cloud and hybrid-cloud operations.

Management Domain and Workload Domain Concepts
The Management Domain contains the core infrastructure components that run the platform itself, including vCenter Server, NSX Manager, vSAN storage, and SDDC Manager.
Workload Domains host tenant or application workloads and operate independently in terms of lifecycle, capacity scaling, and network boundaries.

VI Workload Domain and Edge Domain
A VI Workload Domain provides compute, storage, and virtual networking resources to general-purpose or application workloads.
An Edge Domain hosts NSX Edge Nodes that provide north–south routing, NAT, load balancing, VPN, and other centralized network services.

Roles of vSphere, vSAN, NSX, and SDDC Manager in VCF
vSphere supplies compute virtualization and cluster features such as HA, DRS, and host lifecycle operations.
vSAN provides hyperconverged, policy-driven storage across VCF domains.
NSX delivers software-defined networking, security, overlay networks, distributed routing, and micro-segmentation.
SDDC Manager orchestrates deployment, lifecycle management, upgrades, and configuration drift remediation across all domains.

VCF Logical Architecture (Management Plane, Data Plane, Network Plane)
The management plane includes vCenter Server, NSX Manager cluster, SDDC Manager, and supporting services.
The data plane includes ESXi hosts, vSAN disk groups, NSX transport nodes, and the runtime resources consumed by workloads.
The network plane consists of the physical underlay, NSX overlay networks, gateways, and Edge Node connectivity.

Key Differences Between VCF and Traditional vSphere Architecture
VCF enforces a prescriptive architecture with standardized deployment and automated lifecycle management.
Traditional vSphere allows custom designs but requires manual upgrades, version coordination, and independent NSX/vSAN planning.
VCF introduces workload domains, automated BOM management, and strict version interoperability across components.

2. High Availability (HA), Fault Domains, and Multi-Site Architectures

vSAN Fault Domains
Fault domains group hosts so that failures affecting a rack or physical location do not compromise data redundancy. vSAN spreads object components across fault domains to avoid correlated failure risks.

vSphere/vSAN Stretched Cluster Models
A stretched cluster spans two sites with a witness host in a third location. It provides site-level resilience where workloads can survive the loss of an entire site without data loss.
vSphere HA restarts VMs, while vSAN synchronously mirrors storage across sites.

Single-Site, Multi-Site, and Active-Active Architectural Models
Single-site designs centralize all resources in one datacenter.
Multi-site designs replicate compute and storage for disaster recovery or load distribution.
Active-Active (or dual-active) architectures allow simultaneous operation in two datacenters with continuous data availability.

RPO and RTO Architectural Impact
RPO defines the acceptable amount of data loss during a failure.
RTO defines how quickly workloads must be restored.
Lower RPO/RTO requirements directly influence replication technology choices, cluster design, network bandwidth, and storage strategy.

General DR Models: Cold Standby, Warm Standby, Active-Active
Cold standby uses powered-off or minimally provisioned environments and has higher RTO.
Warm standby keeps systems online with delayed synchronization, providing moderate RPO/RTO.
Active-Active keeps both sites fully operational with near-zero RPO/RTO.

3. Identity and Access Control Architecture

vCenter Single Sign-On (SSO): Identity Sources, Groups, and Roles
SSO authenticates users and centralizes identity management. Identity sources may include Active Directory, LDAP directories, or local SSO users.
SSO groups map users to roles, while RBAC permissions determine what actions they can perform in the vSphere inventory.

VCF Integration with AD, LDAP, and Enterprise Identity Providers
VCF allows vCenter and NSX to integrate with enterprise directories using LDAP, Kerberos, SAML, or OIDC.
Identity federation enables MFA, conditional access, and centralized identity lifecycle operations.

RBAC and the Principle of Least Privilege
Roles should grant only the minimum permissions required.
Segregation of duties ensures administrative boundaries for compute, storage, and network teams.

Multi-Tenant and Multi-Team Isolation Models
vSphere uses Folders and Resource Pools for organizational separation.
vSphere with Tanzu uses Namespaces and Projects to provide isolation for development teams, policies, and quotas.

4. Observability Framework

Core Observability Components: Metrics, Logs, Traces
Metrics provide numerical measures such as CPU usage, IOPS, or latency.
Logs record system events, warnings, and operational data.
Traces capture request flows across distributed systems, useful in microservices environments.

Common Monitoring Targets in vSphere and VCF
Clusters, ESXi hosts, vSAN datastores, NSX transport nodes, Edge Nodes, logical networks, and SDDC Manager are all key components requiring continuous monitoring.

Syslog Aggregation Architecture
Centralized log collection enables correlation across vCenter, ESXi hosts, NSX components, and vSAN services.
Syslog servers or platforms like vRealize Log Insight provide retention, alerting, and forensic analysis.

Alerts, Events, and ITSM Integration
Alerts and events can be forwarded to ITSM systems such as ServiceNow.
Integration supports automated incident creation, change tracking, and compliance reporting.

5. Capacity Planning, Resource Governance, and Cost Awareness

Capacity Planning Factors (CPU, Memory, Storage, Network, Licensing)
Capacity calculations must account for average and peak usage patterns, HA reserves, storage growth, network throughput needs, and licensing constraints.
Improper sizing can lead to contention, degraded performance, and unplanned expansion costs.

Upgrade Windows and HA Resource Reservation
Clusters must maintain enough headroom to support host failures and rolling upgrades.
N+1 or N+2 host designs ensure resources remain available even during maintenance events.

Using Tags and Policies for Resource Grouping and Governance
Tags allow workloads to be grouped and targeted with storage policies, compliance rules, affinity constraints, or automation workflows.
Policies enforce consistent placement, encryption, QoS, or lifecycle configurations.

Chargeback and Showback Concepts
Chargeback allocates actual infrastructure costs to consuming business units.
Showback reports consumption without enforcing financial billing.
Both support budgeting, forecasting, and accountability in private-cloud environments.