Running Deployment

Once the deployment is initiated, the CF root stack further triggers nested stacks. CF also launches several Lambda functions:

• lbinfra nested stack - will deploy networking and security resources and infrastructure.
• lbapp nested stack - will deploy the storage EC2 instances and deploy the Lightbits software.
• lbexporter nested stack - will deploy all of the resources required for backup/restore.

The CF stacks will also launch several serverless Lambda functions that run periodically to manage various aspects of the cluster:

• deploy_lambda - this Lambda runs once at deployment initiation. It manages the initial cluster configuration and the initial software execution over each storage instance. Once the deploy-lambda has been completed successfully, the storage cluster is up and running.
• maintenance_lambda - this Lambda is scheduled and will run every 1-2 minutes. It is responsible for the maintenance activities of the cluster, such as automatic scaling, automatic healing in case of instance failure, and handling upgrades. See Auto Maintenance Overview for additional information.
• cleanup_lambda - this Lambda is used to assure proper resource cleanup when the stack is being deleted - specifically in regards to log groups.
• backup_lambda - this Lambda is scheduled and will run every 1-2 minutes. It is responsible for scheduling and executing backup and restore requests. See Backup and Restore for additional information.

Lightbits SDS deployment takes approximately 15-20 minutes to complete. Once complete, the storage cluster is active and you can start using it.

In AWS console, the deployment is done once all stacks (root + nested) are in ‘CREATE_COMPLETE’ state.

If the create fails and there are stacks in failed/deleted state, refer to Troubleshooting Deployment Failures.

After stack deployment is completed, the Lightbits cluster can be accessed in several ways:

• Terminal access should be done via AWS Session Manager, or SSH to the IP address of the required instance in the cluster. The lbcli command interface can then be used to manage the Lightbits cluster (e.g., create volume).
• API access should be via the VIP or the DNS name of the NLB (port 443).
• Client discovery access should be via the VIP or the DNS name of the NLB (port 8009).
• The lbcli command interface can also be done from any client that is part of the security group CIDR, and should be via the VIP or the DNS name of the NLB (port 443).

Clients should have the discovery controller installed to query the network and discover the Lightbits cluster.

This is supported natively on the following operating systems:

• AlmaLinux 9
• RHEL 9
• Rocky Linux 9
• Ubuntu 22.04
• Ubuntu 20.04
• Amazon Linux
• VMWare ESXI 7.0.3 (also requires a VCP plugin)
• Linux distribution with kernel version 5.4 and newer

Note that if the clients are deployed outside the storage cluster's VPC, a VPC peering connection must be made between the clients VPC and the Lightbits cluster VPC.

For detailed information on storage usage, refer to Common Administration Tasks.