CycleCloud 6 feature: cluster upgrade button

This post is one of several in a series describing features introduced in CycleCloud 6, which we released on November 8. When you create a CycleCloud cluster, it gets “pinned” to the version of CycleCloud you’re running. This means the images and automation tools will stay within the same release series to prevent an unexpected changes in behavior. When you upgrade your CycleCloud installation, clusters will continue using the same version they were created with until you decide to upgrade it. This allows you to upgrade clusters on your own schedule. New in CycleCloud 6 is a button to perform the upgrade on terminated clusters. The “Upgrade” button will appear for any cluster that is set to a previous version. If the cluster is terminated, you can click the button to upgrade the cloud images and automation suite. Running clusters cannot be upgraded in order to prevent a cluster from running mixed versions. Once you click the Upgrade button, CycleCloud will update the internal record to use the new version. You can immediately click Start to launch your upgraded...

CycleCloud 6 feature: Improved HealthCheck framework

This post is one of several in a series describing features introduced in CycleCloud 6, which we released on November 8. CycleCloud’s HealthCheck system provides a mechanism for detecting and terminating bad instances. The definition of “bad” can vary by use case, so HealthCheck provides a framework for custom scripts to use instead of prescribing a defined state. HealthCheck runs customer-provided Python and shell (Unix shell or Windows batch, as appropriate) on cloud instances regularly. New in CycleCloud 6, we’ve made it safer and easier for users to create custom health checks for the clusters. The HealthCheck system requires an explicit return code (254) to terminate an instance. This removes the possibility of an error in the script itself causing CycleCloud to terminate an instance. A return code of 0 still indicates a healthy system, and any other exit code is logged to CycleCloud’s Event Log. At SC16? Stop by booth #3621 for a...

CycleCloud 6 feature: Easier SSL certificate handling

This post is one of several in a series describing features introduced in CycleCloud 6, which we released on November 8. Managing SSL certificates in Java can be a daunting task, but using them is important to provide secure communication to the server. CycleCloud 6 adds a new feature to help manage these certificates. To create and install a self-signed certificate or generate a certificate signing request (CSR) to send to a certificate authority (CA) for signing, use the create_request subcommand. For example, to create a CSR for the host cycleserver.example.com: ./cycle_server keystore create_request cycleserver.example.com This will create and install a self-signed certificate. CycleCloud will begin using that certificate immediately with no restart required. The CSR is written to cycle_server.csr, which can be sent to your CA if you do not want to continue using a self-signed certificate. Once you have the signed certificate bundle, save it to a directory (for example, certs/) and run: ./cycle_server  keystore import certs/domain.key certs/*.crt Your CycleCloud installation is now using the signed certificate. At SC16? Stop by booth #3621 for a...

CycleCloud 6 feature: Selection UI for Cluster-Init and Custom Chef

This post is one of several in a series describing features introduced in CycleCloud 6, which we released on November 8. CycleCloud’s Cluster-Init and Custom Chef features provide the flexibility and automation needed for IT organization to provide a Cluster-as-a-Service offering to their users. New in CycleCloud 6 is the ability to graphically browse to the desired Cluster-Init and Custom Chef directories. When creating a new cluster, the Software screen has options for setting the (optional) Cluster-Init and Custom Chef locations. Clicking the “Browse” button brings up a file browser window you can use to select the right option for your cluster. At SC16? Stop by booth #3621 for a...

CycleCloud 6 feature: MPI optimizations

This post is one of several in a series describing features introduced in CycleCloud 6, which we released on November 8. Batch workloads have long been a natural fit for cloud environments. Tightly-coupled workflows (e.g. MPI jobs) are sensitive to bandwidth, latency, and abruptly-terminated instances. MPI workloads can certainly be run on the cloud, but with guardrails. CycleCloud 6 adds several new features that make the cloud even better for MPI jobs. MPI jobs can’t make use of a subset of cores; they need all-or-nothing. CycleCloud now considers the minimum core count necessary for the job and sets the minimum request size. In other words, if the provider cannot fulfill the entire request, it won’t provision any nodes. Similarly, CycleCloud 6 also adds support for Amazon’s Launch Group feature, which provides all-or-nothing allocation for spot instances. This opens the spot marketing to MPI jobs, which can represent significant per-hour savings. To address the latency concern, CycleCloud now dynamically creates AWS Placement Groups for MPI jobs. This groups instances logically nearby, minimizing latency. At SC16? Stop by booth #3621 for a...