Triton DataCenter Documentation

Triton DataCenter (Triton) is an open-source cloud management platform that provides container-based, service-oriented infrastructure across one or more data centers. It is built on top of SmartOS and uses SmartOS zones for high-performance container virtualization, with KVM support for Linux and Windows guests.

A standard installation consists of:

• Management Server (Head Node): Houses the core services that drive Triton.
• Compute Nodes (CNs): Run instances (containers and virtual machines) and run agents in their global zone for management and monitoring.

Key features include a public RESTful API for managing instances, networks, users, and images; a complete operator portal (web app); and automated installation via USB, ISO, or iPXE.

Cloud on a Laptop (CoaL) is a VMware appliance that provides a full Triton head node for development and testing purposes. It is designed to allow developers (particularly those on macOS) to run a local Triton environment.

Warning: This installation is intended for development and testing only; it is not suitable for production deployments.

vminfod is a daemon that provides a read-only cache of VM information (such as zones, HVM, and LX zones) via an HTTP interface. It is accessible on 127.0.0.1:9090 from the system's global zone.

Key behaviors:

• Caching: It serves as a cache, only querying the system for new information when modifications are detected.
• Read Operations: Commands like vmadm list, vmadm lookup, and vmadm get act as thin wrappers around HTTP requests to vminfod.
• Write Operations: Read-write commands (e.g., vmadm create, vmadm reboot, vmadm update) interact with the system directly but will "block" on vminfod until the changes are reflected in the cache before returning to the caller.
• Event Streaming: It provides a streaming interface via long-polling the /events endpoint to notify consumers of system changes (creation, deletion, or property modifications).

Triton and Manta consist of an operating system, various service components, and administrative tools. Many components run inside dedicated SmartOS zones.

Components are typically formed from a base image (or origin image) containing specific pkgsrc packages, combined with the software implementing the service. Some components run on the 'global zone', while others run in specific zones.

When building, you must ensure your build zone runs the same pkgsrc release that the component will be deployed with.

Build zones are isolated environments used to build Triton and Manta components. They consist of base pkgsrc packages, development packages, and specific build tools. To ensure compatibility, build zones must match the origin image of the component being deployed.

Supported Platforms

You can run build zones on two primary platforms:

• Triton: A full Triton installation. It is more resource-intensive but scalable beyond a single system.
• SmartOS: A lighter, easier-to-set-up alternative that hosts the build zones.

Platform Version Validation

Joyent's production builds require the Platform Image (the kernel and userland) to meet a minimum version defined by min_platform. If you are using a platform image that is older than what the component expects, set the following environment variable to bypass validation:

$ENGBLD_SKIP_VALIDATE_BUILD_PLATFORM=true

A Triton Head Node can boot from a ZFS pool instead of a traditional USB-key. The sdc-usbkey command functions nearly identically on a disk-booting Head Node, with the exception that the ZFS bootable filesystem is case-sensitive.

To ensure compatibility with both BIOS and EFI servers, a bootable ZFS pool SHOULD be created using the -B flag.

Recommended disk configurations for bootable pools:

• Single disk.
• Two (mirrored) or more (raidz) same-sized disks.
• Two or more same-sized disks with a single SSD for a log device.

Note: Log devices, log device mirrors, or cache devices can be added to the pool after installation.

ZFS Pool Requirements

To boot the Head Node from a ZFS pool, you must properly set up a bootable ZFS pool. Refer to the documentation on Booting the Head Node from a ZFS Pool for specific configuration details.

Boot Order Configuration

Because the Triton installation process triggers a reboot, you must configure your hardware's boot order to prevent the system from looping back into the installer.

Recommended Boot Order:

1. Hard drives (Primary)
2. DVD drive (Secondary)

SmartDataCenter (SDC) configuration is split into two main groups:

1. Headnode configuration: Stored locally in [/mnt]/usbkey/config.
2. Service configuration: Stored as metadata (key/value pairs) within the SAPI (Services API) hierarchy.

The SAPI hierarchy follows this structure:

• Application (e.g., sdc, manta)
  • Service (e.g., vmapi, cnapi, manatee)
    • Instance (e.g., individual VMs; the Instance UUID is the VM's UUID)

Configuration for an individual instance is typically generated by the config-agent service, which renders a sapi_manifest template using the combined metadata from the Application, Service, and Instance levels.