DOCSEARCHbyAlgolia
Submit Docs

E2E Cloud Documentation

website·Indexed 35 days ago

https://docs.e2enetworks.com

Documentation for E2E Cloud, an Indian cloud platform providing compute nodes, GPU instances, managed databases, and Kubernetes. Includes comprehensive guides on managing Kubernetes clusters, node pools, persistent volumes, networking, security groups, and integrations with DBaaS and Object Storage (EOS), as well as setup guides for Argo CD, Istio, and Velero.

Tokens
114.4K
Snippets
314
Records
853
Agent score
61%

What's inside E2E Cloud

  1. Overview of E2E Marketplace Nodes

    A marketplace node is a standard E2E compute node launched from a prebuilt product image. Unlike a plain OS image, marketplace images include a prepared software stack, application, or appliance (e.g., Apache Airflow, Django, databases, or AI applications).

    Use a marketplace node when you need a faster starting point and the included stack matches your workload. Use a standard CPU or GPU OS image if you require a clean server, full control over package versions, or a specific OS/licensing model not available in the marketplace.

    Note: You remain responsible for managing OS updates, application updates, access control, backups, and security groups unless the specific product documentation states otherwise.

  2. Overview of TIR Slurm Cluster for GPU Training

    TIR Slurm Cluster (labeled as 'Training Cluster' in the TIR portal) is a managed Slurm scheduler running on Kubernetes through the Slinky operator. It provides a login node for job submission, a controller for scheduling, and GPU worker nodes for execution. Key capabilities include:

    • Containerized Jobs: Run any Docker or OCI image using srun --container-image=... via Enroot and Pyxis without requiring a cluster rebuild or Docker daemon.
    • Customizable Configuration: Users can append custom directives to the slurm.conf via the console.
    • Custom Partitions: Ability to define named queues with specific limits and node membership.
    • Lifecycle Scripts: Support for custom Prolog and Epilog shell scripts that run on workers and the controller around every job.

  3. Overview of Slurm Cluster Login User Management

    Login User Management allows team members to have individual SSH identities on a Slurm Cluster. This provides each user with their own login name, SSH keys, and a private home directory (mode 0700) on shared storage. Key benefits include:

    • Individual accountability (jobs are attributed to specific users instead of root).
    • Granular job control (users can only cancel their own jobs via scancel).
    • Secure access revocation (removing one user does not affect others).
    • Persistent, private home directories on shared storage.

  4. Overview of Slurm Partitions in TIR

    A partition is a named queue over a specific set of nodes with its own time limits and defaults. TIR Slurm Clusters include platform-managed partitions covering all nodes by default. Users can add up to 20 custom partitions via the console without requiring SSH access. Custom partitions are written to slurm.conf.

  5. Overview of Auto Scaling in MyAccount

    Auto Scaling in MyAccount allows you to manage 'scale groups' that automatically grow or shrink a pool of compute nodes based on a defined policy. This ensures applications remain responsive during peak demand and reduce costs during low-traffic periods. The Scaler handles launching/terminating nodes from a saved image and registering/de-registering them with a load balancer. Scaling can be triggered by CPU usage, custom metrics, a predefined schedule, or a combination of these factors. To access these features, navigate to Compute > Auto Scaling in the MyAccount left navigation menu.

  6. Overview of the kube-prometheus-stack

    The kube-prometheus-stack is a pre-configured set of tools designed to gather metrics from all Kubernetes components. It consists of three primary components:

    1. Prometheus Operator: Manages Prometheus instances within the cluster.
    2. Grafana: Provides visualization of metrics via dashboards and supports PromQL queries.
    3. Alertmanager: Handles deduplication, grouping, and routing of alerts to receivers like Slack, PagerDuty, or email.

  7. Overview of Custom Scaling Policies

    A custom scaling policy allows the Scaler to make scaling decisions based on any chosen metric (e.g., memory usage, network traffic, disk I/O, request count, or queue depth) instead of the default CPU metric. The Scaler reads a specific custom attribute from every node in the group, calculates the average value, and applies scale-up and scale-down thresholds to that average to determine if the group should increase or decrease cardinality.

  8. Overview of TIR Slurm Cluster features

    TIR Slurm Clusters provide a managed Slurm environment that includes the following core capabilities:

    • Managed Slurm: Full support for sbatch, squeue, sacct, partitions, priorities, and accounting without needing to install or patch the scheduler.
    • Container Support: Ability to run Docker or OCI images within jobs using the --container-image flag, providing unprivileged execution and native GPU access.
    • Custom Configuration: Support for appending custom directives to slurm.conf via the console and creating up to 20 custom named queues (partitions) with specific time limits and node memberships.
    • Lifecycle Scripts: Four available slots for Prolog and Epilog scripts (worker and controller, before and after jobs) for setup, cleanup, and auditing.
    • Elasticity & Storage: Ability to add or remove worker nodes on a live cluster without affecting running jobs. Shared storage (PFS, SFS, Weka, and read-only datasets) is mounted at the same path across login and worker nodes.
    • Monitoring & Health: Per-node and per-GPU metrics (utilization, memory, temperature, power) via DCGM, XID error detection, and browser-based squeue and log monitoring.
    • User & Network Management: Per-user SSH identities with private home directories on shared storage, and network control via Reserved/VPC IPs and security groups.
    • Automation: Full REST API coverage for all console actions to enable end-to-end automation of provisioning and management.

  9. Overview of E1 Series Nodes

    E1-series nodes are cost-focused compute nodes available for both Linux and Windows. While they share common lifecycle actions (monitoring, security groups, backups, snapshots) with other node families, they have specific behaviors regarding root storage, public IP assignment, billing during Stop/Power Off states, and plan updates.

  10. Overview of E2E Cloud Platform

    E2E Cloud (E2E Networks) is an Indian cloud platform providing infrastructure including compute nodes, GPU instances, managed databases, Kubernetes, object storage, networking, security, and AI/ML infrastructure. The primary management interface is the MyAccount portal located at https://myaccount.e2enetworks.com.

  11. Overview of Application Load Balancer (ALB) ACL Routing

    Access Control List (ACL) rules enable Layer-7, content-based routing for Application Load Balancers (ALB). They allow requests to be routed to different backend groups based on specific request attributes. ACLs are only available for ALBs (not Network Load Balancers) and can be managed when the ALB is not in a Creating, Deploying, or Deleting state.

  12. Overview of Slurm Prolog and Epilog Script Slots

    Slurm provides four script slots to automate tasks around job execution. These scripts run automatically for every job without requiring changes to the user's job script.

    SlotRuns onTimingSlurm DirectiveUse Case Examples
    Worker PrologEvery worker node in allocationBefore each job starts on that nodePrologSet up per-node scratch space, warm cache, hardware health checks
    Worker EpilogEvery worker node in allocationAfter each job ends on that nodeEpilogDelete temporary files, flush node-local logs to shared storage
    Controller PrologSlurm controllerOnce per job, at allocationPrologSlurmctldRecord job in external system, notify webhooks, enforce central policy
    Controller EpilogSlurm controllerOnce per job, at completionEpilogSlurmctldPost results to tracker, send completion notifications, aggregate accounting

    Key Distinction: Worker scripts run once per node (e.g., 4 times for a 4-node job), while controller scripts run exactly once per job.