Skip to main content

Create an instance with replicated disks

This guide creates an instance whose data disk, or boot disk, is a replicated MantaBlock volume, then confirms the disks and grows a local one. For what the storage classes mean, see How instance disks work.

Before you start, you need:

  • Everything Create an instance needs: tritonctl signed in, a project set, a subnet, and an SSH key.
  • A role that allows replicated disks. A create with a replicated disk is checked against the ReplicatedDiskCreate action as well as InstanceCreate.

Step 1: Find your silo​

On your workstation:

tritonctl whoami

The tenant: line ends with silo: <SILO_UUID>. You need that UUID in the next step.

Step 2: Check the storage classes your silo offers​

Read the silo's provisioning policy:

tritonctl api GET /v1/silos/<SILO_UUID>/provisioning-policy

The storage_classes field lists the classes you can use and the copy count for every replicated disk. A silo that offers both replicated classes prints a fragment like:

"storage_classes": {
  "enabled": ["local", "replicated_standard", "replicated_performance"],
  "copies": 3
}

If enabled holds only local, the silo offers no replicated storage. Ask your operator to enable a replicated class; you cannot change it yourself.

Step 3: Create the instance​

Pick one of the two forms below. An instance can have a replicated data disk or a replicated boot disk, not both.

A local boot disk and a replicated data disk​

On your workstation:

tritonctl instance create \
  --name db-1 \
  --image <IMAGE_NAME> \
  --subnet <SUBNET_NAME> \
  --ssh-key workstation \
  --cpu 2 \
  --memory 4G \
  --disk size=100G,class=replicated_standard \
  --wait

The data disk must be a whole number of GiB, from 1 GiB to 16 TiB. Name either replicated class your silo offers. To take the silo's default replicated class, write --data-disk 100G in place of the --disk line: it gets replicated_performance when the silo offers it, and replicated_standard otherwise. Do not add replicas= or tier=; the server refuses both from a tenant.

A replicated boot disk​

The image must be a bhyve image with a source URL and a SHA-256 checksum. Other images are refused for a replicated boot disk.

On your workstation:

tritonctl instance create \
  --name app-1 \
  --image <IMAGE_NAME> \
  --subnet <SUBNET_NAME> \
  --ssh-key workstation \
  --cpu 2 \
  --memory 4G \
  --disk boot,size=50G,class=replicated_performance \
  --wait

Omit size= to size the boot disk from the image. With --package, the package sets the boot disk size, so leave size= out.

Step 4: Confirm the disks​

List the instance's disks. Use db-1 or app-1, whichever you created:

tritonctl disk list --instance db-1

The CLASS column reads replicated_standard or replicated_performance for the replicated disk, and local for a local one. The boot disk is named boot and the data disk data0. Add -l to see the COPIES column.

Step 5: Grow the local boot disk​

This step applies to db-1, the instance with a local boot disk. Replicated disks cannot be resized, so app-1 has no disk to grow. To grow the boot disk of db-1 to 200 GiB:

tritonctl disk resize boot --instance db-1 --size 200G

--size is the new total size, and it must be larger than the current one. The instance must be running or stopped. A running instance prints reboot the instance to see the new capacity on stderr. Reboot it:

tritonctl instance reboot db-1 --wait

The guest's cloud-init grows the filesystem at boot.

If something fails​

The server checks the disk specs before it accepts the instance, and answers 400 with the reason. Messages that start with disks: carry the position of the entry in the request, counted from 0. Every message, with its cause, is listed under Disk specs. The ones you are most likely to meet here:

  • choose a storage_class; the silo sets replicas and tier: remove replicas= and tier=, and name a class=.
  • this silo does not offer <CLASS> storage: pick a class from step 2, or ask your operator.
  • Replicated disks are not available here right now. Use local disks, or ask your administrator.: too few compute nodes can hold the copies right now.

tritonctl refuses a few specs before it sends a request, for example give one boot --disk for two boot entries.

disk resize errors, including the one for a replicated disk, are listed under tritonctl disk resize.

See also​