...
Power on each chassis planned as a Swarm storage node. Each chassis PXE boots from the Platform server, enlists itself with Platform, and shuts itself down.
List the chassis currently available to run Swarm after enlistment completes:
Code Block language bash platform list nodes
The number of chassis returned is the value to use in the next step for
-n
, unless some are kept in reserve.Deploy Swarm Storage to the chassis being managed by Platform:
Code Block language bash platform deploy storage -v {#.#.# Version of Swarm Storage} -c {Path to cluster.cfg} -n {# Nodes To Deploy}
At this point, the Platform powers on each of the nodes twice. The first power on is commissioning, involving hardware interrogation and other tasks, which ends with a power off. The second power on is to boot Swarm Storage on the chassis.
Once Swarm is running, deploy Content Gateway, or, if not using Content Gateway, proceed to Deploying a Proxy.
Code Block language bash platform deploy proxy -b {Path to Service Proxy Bundle zip}
Power Control with ESXi
With a VMware ESXi hypervisor, you may want It may be ideal to use local Storage VMs with a VMware ESXi hypervisor. These VMs enlist, but the power type is not detected by MAAS. Commissioning and deployment requires the "Manual" power type (see next), and requires manually powering on these VMs (shutdown works).
...
When a chassis is powered on for the first time, the Platform Server auto-detects which power mechanism to use when processing them for deployment. However, if a chassis has IPMI for power control of the chassis but you need Platform server to ignore IPMI, you must switch Switch the deployment to manual power control (add the --manual
flag to the platform deploy
command) and then manually power on machines at the right time as they go through the lifecycle if a chassis has IPMI for power control of the chassis but require Platform server to ignore IPMI.
When using manual power control, you need to use CLI commands to know when to power on each chassis, so use the -y <system-id>
flag, rather than -n <# of nodes>
.
Run the deploy command for an individual chassis, using the
--manual
flag and the-y <system-id>
flag.To Use the
--state Commissioning
flag to know when to turn the chassis on, use the--state Commissioning
flag:Code Block language bash platform list nodes --state Commissioning
As Power on the chassis as soon as the chassis appears in the list, you can power on the chassis.
After you power on the chassis, it The chassis goes through commissioning after being powered on and then powers itself off.
To Use the
--state Deploying
flag to know when to power on the chassis for the final time (to deploy the Storage software), use the--state Deploying
flag:Code Block language bash platform list nodes --state Deploying
As Power on the chassis for the final time as soon as the chassis appears in the list, you can power on the chassis for the final time.
Info |
---|
TipYou can also use Use the following CLI command to follow the chassis through its lifecycle stages. |
...
Changing Network Bonding Mode
By default, the The Platform server boots all Storage chassis using the "balance-alb" bonding mode . You can modify the by default. The default bonding mode to use used can be modified for future deployments by using the following command:
...
Info |
---|
Bonding modesSee Network Devices and Priority for details on bonding modes. |
To Override the default value by using the --bondingMode
flag to use a different bonding mode when deploying an individual chassis, override the default value by using the --bondingMode
flag:
Code Block | ||
---|---|---|
| ||
platform deploy storage -v <#.#.# Version of Swarm Storage> -c <Path to cluster.cfg> -y <system-id> --bondingMode "<bonding-mode-to-use>" |
To Run the add kernelparam
command to modify the bonding mode for a chassis that's already deployed, run the add kernelparam
command:
Code Block | ||
---|---|---|
| ||
platform add kernelparam -y <system-id> --kernel_params "castor_net=<bonding_mode>" |
After Restart the chassis after the command completes, restart the chassis.
Configuring Subclusters
After Assign chassis to subclusters after all the chassis have been deployed and are running, you can assign chassis to subclusters.To .
Use the assign
command to assign a chassis to a subcluster, use the assign
command:
Add to subcluster
Code Block | ||
---|---|---|
| ||
platform subcluster assign -y <system-id> --subcluster <subcluster-name> |
Info |
---|
NoteAssignment is not immediate. Allow time for every node on the chassis to be migrated to the new subcluster. |
To Use the list
command to review the subcluster assignments, use the list
command:
List subclusters
Code Block | ||
---|---|---|
| ||
platform subcluster list |
...