Linux Compute Node Installation
Prerequisites
- Latest TRITON updates of all components (At least release-20210923)
- Additional updates and bug fixes will be available from the dev channel in advance of Triton releases.
- Available hardware compute node for LXC Instances
Platform Image / Process / Installation
Linux CN platform images are available in Manta at https://us-central.manta.mnx.io/Joyent_Dev/public/TritonDCLinux
It is advised to reboot all Linux Compute Nodes to the latest available platform. Before filing any bugs, issues must be tested on the latest platform with all agents up to date.
Use the following commands to install the latest platform image:
mkdir /var/tmp/linuxcn
cd /var/tmp/linuxcn
curl -o https://us-central.manta.mnx.io/Joyent_Dev/public/TritonDCLinux/joyent-debian_live-latest.usb.gz
sdcadm platform install ./joyent-debian_live-latest.usb.gz
You can then use sdcadm platform assign
as normal. Note that platforms can
only be assigned to the same OS type or an unsetup CN.
Networking
Please take special note that all NICs assigned to LXC instances behave as if
allow_ip_spoofing
, allow_mac_spoofing
, allow_dhcp_spoofing
, and
allow_unfiltered_promisc
are enabled, due to how Linux handles networking for
containers. Please note, LXC instances should not be run by untrusted end
users in shared networks due to their ability to spoof IP addresses on shared
subnets or networks. Dedicated vlans for LXC instances, or trusted network
pools should only be available for LXC instances. In order to disallow LXC
instances from being deployed to shared networks, use of LXC separate packages,
images or users should be granted access with specific network ownership to
test these instances.
Linux CNs use nic_tags as normal. CNs must be rebooted before nic_tag changes will take effect.
Importing Supported Images
LXD images provided by linuxcontainers.org or Canonical used with Triton must meet the following requirements.
Images must:
- have cloud-init. Most “cloud” variant images in the
images:
remote should work. All images inubuntu:
should have cloud-init installed. - Due to a bug in NetworkManager, CentOS and other RHEL derived images do not currently work
- Images must be of type
CONTAINER
. CurrentlyVIRTUAL-MACHINE
images are not supported. - Images must be i686 or x86_64 architecture
To import images, first use the lxd
command on a running Linux CN to list
images from either the images:
or ubuntu:
remote.
lxc image list images:
lxc image list ubuntu:
Once you have the list of images, choose a suitable image, such as
images:debian/11/cloud
or ubuntu:f
. On the Triton headnode, call the API to
import the image. Note that images can currently only be imported by the alias.
sdc-imgapi /images?action=import-lxd-image\&alias="images:debian/11/cloud" -X POST
Images are initially only usable by the admin
user. You will need to add
individual users to the image ACL or make the image public. Refer to the
imgapi
documentation for details. You may also use the AdminUI
web interface to set the ACL.
Packages
Special package traits are not needed, but traits may be applied to CNs and packages as normal. Operators that prefer to utilize separate LXC packages for LXC instances may use traits or brands to isolate LXC Instances to specific packages.
Known Triton Gaps / Divergences / Issues
Linux LXC containers do not support the following Triton features.
sdc-oneachnode
depends on the headnode’s PATH variable, and can’t find things (e.g.,vmadm
) on Linux CNs.- CentOS images fail due to LXD bug
- CMON metrics
- Delegated ZFS dataset
- Fabric Networks (may be added at a future date)
- Instance resize
- Metadata GET/PUT from inside the container (in progress)
- User-scripts (in progress)
- Volumes (may be added at a future date)
- Triton Custom Image (may be added at a future date)
/native
tools (adding soon)- Triton Cloud Firewall (may be added at a future date)
- LXD public image coverage (not all are yet supported)
- CPU Fair Share Scheduler / CPU Package Caps
CPU Capacity Management
CPU capacity management uses different mechanisms on Linux. This means that when a compute node is not under load, instances are able to burst higher and for longer without CPU scheduling by Triton, utilizing native Linux cpu scheduling features. This may give the false impression that performance is “degraded” when the CN is under high load. This is not in fact the case. When a CN is under high load, all instances are guaranteed a minimum performance relative to the chosen package and the number/speed of the physical processors. The fact that an instance can consume more than its fair share when load is low does not mean that instances are being deprived of CPU time when load is high.
To put this into Triton/SmartOS terms, LXC instances running on a LinuxCN are allowed unlimited bursting as long as there is bursting capacity available.
Getting Help
Questions, bugs or other comments can find us watching on IRC, mailing list or contacting your account manager if you have enterprise support. We will update this page as gaps are closed and improvements are merged & released.