Terminologies

About Regions

A Region is the largest organizational unit available within a Zergaw CloudStack deployment. Regions represent a grouping of resources in distinct geographic locations.

Key Characteristics:

• Purpose: Regions primarily serve to increase the reliability, fault tolerance, and disaster recovery capabilities of the entire cloud platform. By distributing resources geographically, the cloud can withstand a failure in one location.
• Composition: A Region is composed of one or more Availability Zones (Zones), where each Zone is typically equivalent to a separate physical datacenter.
• User Visibility: While the infrastructure hierarchy beneath is often abstracted, Regions are highly visible to cloud administrators

Current Status:
Currently, Zergaw CloudStack operates a single Region located in Ethiopia. As the platform scales, additional Regions will be introduced to enhance global reach and resilience.

About Zones

A Zone is the second- largest organizational unit within Zergaw CloudStack, nested within a Region. A Zone is generally designed to correspond to a single physical datacenter, providing a level of infrastructure isolation.

Key Characteristics:

• Isolation and Redundancy: The fundamental benefit of Zones is to provide physical isolation and redundancy. Each Zone is engineered to be independent, possessing its own independent infrastructure elements such as power supply, cooling, and network uplink. This ensures that a failure in one Zone does not affect resources running in another.
• Composition: A Zone contains the following key components:
  • One or more Pods.
  • One or more Primary Storage servers (shared by all Pods within the Zone), or Primary Storage associated with specific Clusters.
  • Secondary Storage, which is shared by all Pods and Clusters within the Zone.
• User Interaction: Zones are visible to the end user. When deploying a Guest Instance (Virtual Machine), the user must explicitly select the Zone for deployment. Users must also ensure that their custom Templates are copied to the desired Zones before they can create Guests using those Templates there.

Zone Types:

• Public Zones: Visible and accessible to all users. Any user can create a Guest Instance in a Public Zone.
• Private Zones: Reserved for a specific Domain. Only users belonging to that Domain (or its subdomains) are permitted to create Guest Instances in a Private Zone.

Networking within Zones:

• Intra-Zone Communication: Hosts within the same Zone are designed to be directly accessible to each other, typically residing on the same high-speed network fabric without intermediate firewalls.
• Inter-Zone Communication: Hosts in different Zones can communicate, but traffic may be routed through statically configured VPN tunnels or other network segmentation measures, depending on the network configuration.

About Pods

A Pod is the third-largest organizational unit, contained within a Zone. A Pod frequently represents a single equipment rack or a group of adjacent racks within the datacenter.

Key Characteristics:

• Network Affinity: A crucial characteristic of a Pod is that all Hosts within it are guaranteed to be on the same network subnet. This minimizes latency and simplifies network configuration for the contained resources.
• Composition: A Pod consists of:
  • One or more Clusters of Hosts.
  • One or more Primary Storage servers (which may be shared across the Pod).
• User Visibility: Pods are not visible to the end user and serve purely as an administrative and infrastructure organization layer.

About Clusters

A Cluster is the fourth-largest organizational unit and is contained within a Pod. It represents the smallest logical grouping of compute resources.

Key Characteristics:

• Resource Homogeneity: The Hosts within a Cluster must be homogeneous. This means they must all:
  • Have identical hardware specifications (CPU, RAM).
  • Run the same hypervisor type (e.g., all XenServer, all KVM, or all VMware ESXi).
  • Reside on the same network subnet (inherited from the Pod).
  • Access the same shared Primary Storage.
• Hypervisor Grouping: A Cluster aligns with hypervisor-specific groupings: a XenServer Server Pool, a set of KVM servers, or a VMware cluster preconfigured in vCenter.
• Live Migration: The homogeneity requirement enables core cloud functionality, such as live-migration of Instances from one Host to another within the same Cluster without service interruption.

About Hosts

A Host is the smallest organizational unit and represents a single physical server. Hosts provide the actual computing resources that run the user's workloads, known as Guest Instances (Virtual Machines).

Key Characteristics:

• Role: Hosts provide the core resources: CPU, memory, storage (local), and network bandwidth.
• Hypervisor: Each Host has hypervisor software installed (e.g., Citrix XenServer, Linux KVM, VMware ESXi, or Windows Hyper-V) to manage and run the Guest Instances.
• Hierarchy: Hosts are contained within Clusters, which are in Pods, which are in Zones, which are optionally in Regions.
• Scalability: Additional Hosts can be added to existing Clusters at any time to increase overall capacity.
• Resource Detection: Zergaw CloudStack automatically detects and manages the amount of CPU and memory resources provided by the Hosts.
• User Visibility: Hosts are not visible to the end user. Users cannot determine which specific Host their Guest Instance has been assigned to.

Storage Components

Zergaw CloudStack leverages a distinct hierarchy of storage components to serve different purposes.

Primary Storage

Primary Storage is the high-performance storage associated with a specific Cluster.

• Purpose: It stores the virtual disks (volumes) for all Guest Instances currently running on the Hosts within that Cluster.
• Access: It must be accessible via high-speed, low-latency links to all Hosts in its associated Cluster.

Secondary Storage

Secondary Storage provides a shared repository for persistent, read-only data assets. It is shared by all Pods and Clusters within a Zone.

• Purpose: It stores reusable, static assets, including:
  • Templates: Base OS images used to boot Instances, often including pre-installed applications or configurations.
  • ISO Images: Disc images containing data or bootable media.
  • Disk Volume Snapshots: Saved copies of Instance data used for recovery or creating new Templates.

Object Storage

Object Storage is a highly scalable, non-hierarchical data storage system.

• Data Model: It manages data as self-contained objects (data, unique identifier, and metadata), rather than as files or blocks.
• Buckets: Users interact with Object Storage by creating buckets, which are logical containers for storing objects. Object storage is ideal for unstructured data, backups, and archival use cases.

About Shared FileSystems

The Shared FileSystem feature allows Zergaw CloudStack users to deploy and manage a highly available, multi-client storage solution mounted via NFS (Network File System).

Deployment and Access:

• Deployment: The Shared FileSystem is deployed on a dedicated Guest Instance with a user-specified Service Offering. A separate data volume is attached, formatted (e.g., using XFS or EXT4), and then exported via NFS.
• Client Access: All Guest Instances within the same guest network can mount the exported Shared FileSystem, enabling them to read and write data to the shared space.
• Configuration: Users have control over the underlying resources, choosing the desired service offering (compute power), disk offering (storage capacity/performance), filesystem format, and network configuration.