Migrating to Starburst Enterprise 426-e or higher#

As of the Starburst Enterprise platform (SEP) 426-e release, privileged access to the attached storage on nodes is no longer required for Starburst Warp Speed cluster configuration in Helm deployments. Existing cluster configurations must be updated, with EKS deployments requiring the addition of a bootstrap script.

Overview#

As of SEP 426-e, Starburst Warp Speed deployments use their own filesystem and no longer need to be run with a privileged mode in cloud providers. A new autoConfigure property was added to the Starburst Warp Speed Helm chart which dictates whether to automatically configure this new filesystem on launch. This property defaults to false and must be manually enabled on existing SEP deployments on AKS and GKE that upgrade to 426-e or the filesystem is not created:

warpSpeed:
  autoConfigure: true

The following is a migration guide detailing required actions for migrating SEP clusters running Starburst Warp Speed to SEP version 426-e or higher. Contact Starburst Support with questions or feedback.

SEP configuration#

The specific configuration steps depend on which cloud platform SEP is deployed in. The following sections describe the required configuration to migrate SEP clusters running Starburst Warp Speed to a version 426-e or higher in each platform.

All platforms#

Remove the following line from your values file to remove privileged mode access:

securityContext:
  privileged: true

Add the following filesystem and image configuration to your values file:

warpSpeed:
  fileSystem:
    # localStorageMountPath is set to the path for the mount point used to
    # mount the local SSDs. Value differs between clouds:
    # AWS, Azure - Defined by the user
    # GCP - Must be set to /mnt/stateful_partition/kube-ephemeral-ssd
    localStorageMountPath: /opt/data
  image:
    enabled: true
    # Image that prepares the filesystem for Starburst Warp Speed.
    # Due to system limitations, this must be done by an init container
    # running in privileged mode.
    repository: "harbor.starburstdata.net/starburstdata/starburst-warpspeed-init"
    # Tag value differs between clouds:
    # AWS, GCP - Use default tag
    # Azure - Append the "azure" suffix, for example "1.0.0-azure"
    # Update this tag to the latest available version of the Starburst Warp
    # Speed init container
    tag: "1.0.10"
    pullPolicy: "IfNotPresent"

AWS#

Destroying the existing EKS cluster is not required. You can create a new node group and deploy with Starburst Warp Speed enabled, placing worker nodes on the new node group.

Include the following preBootstrapCommands script as part of the node groups creation:

managedNodeGroups:
  preBootstrapCommands:
    "yum install -y mdadm"
    "sysctl -w fs.aio-max-nr=8388608 >> /etc/sysctl.conf"
    'devices=""; for device in $(ls /sys/block/); do if [[ $(grep -e "Amazon EC2 NVMe Instance Storage" -e "ec2-nvme-instance" /sys/block/${device}/device/subsysnqn -c 2> /dev/null) -gt 0 ]]; then devices="${devices} /dev/${device}"; fi; done; echo ${devices} > /tmp/devices'
    "mdadm --create /dev/md0 $(cat /tmp/devices) --level=0 --force --raid-devices=$(cat /tmp/devices | wc -w)"
    "mkfs.ext4 /dev/md0 -O ^has_journal"
    "mkdir -p /opt/data"
    "mount /dev/md0 /opt/data"
    "chmod 777 -R /opt/data"

Azure#

  1. Scale down the worker node pool and wait for all the old machines to be destroyed.

  2. Set the following configuration in values.yaml:

warpSpeed:
  image:
    # Update this tag to the latest available version of the Starburst Warp
    # Speed init container
    tag: "1.0.10-azure"

  1. Scale up the worker node pool and wait for the new workers to connect to the coordinator.

GCP#

  1. Destroy the existing GKE cluster.

  2. Start a new GKE cluster and include ephemeral-storage-local-ssd flag to provision local SSDs.

  3. Set the catalog configuration property warp-speed.file-system-reserve-percentage=80 as highlighted in the Starburst Warp Speed cluster configuration.

FAQ#

Q: Is privileged mode access still required for deploying Starburst Warp Speed?

A: With the recent change in 426, the long-running starburst-enterprise image no longer requires privileged mode access. Privileged mode access is temporarily required in GCP and Azure deployments as part of the Starburst Warp Speed init container execution while setting /proc/sys/fs/aio-max-nr.

Q: Is there a way to remove privileged mode access from the init container as well?

A: AWS EKS allows administrators to set the value of /proc/sys/fs/aio-max-nr via a bootstrap script during node group creation.