▷ the Bright blog

Bright Cluster Manager 9.1 includes an integration with Jupyter Notebook that accomplishes several important things that make Jupyter a more effective and powerful tool for users:

Bright Cluster Manager includes a feature called Auto Scaler that dynamically scales HPC workload management (WLM) and Kubernetes clusters based on workload demand, subject to configured policies. Auto Scaler is the engine that drives the hybrid cloud. It can repurpose and/or re-image on-prem and edge nodes and it can automatically extend the cluster to the cloud. 

I’m pleased to say that now Bright provides cluster management for OpenShift, organizations can manage their OpenShift infrastructure through Bright, unlocking many Bright benefits such as gaining the increased capabilities, flexibility, and extensibility.  

There is a lot of excitement around Bright Cluster Manager 9.1 providing an integration with vSphere, as it allows high-performance clusters to be created and managed without the need for skills and knowledge of vSphere.

Late last year, we announced an integration with Ansible to enable organizations who have standardized on Ansible to gain the power and flexibility that Bright Cluster Manager provides, using their configuration tool of choice.

Those of you who are familiar with Bright probably know that CMSH is the Cluster Management Shell. The CMSH is one of the two administrative interfaces provided by Bright Cluster Manager, the other being Bright View. Most people start off using Bright View, because it’s easy to use. But in time, most admins learn how to use the CMSH because of its power; it allows them to operate on many nodes simultaneously. Here are a couple of tips that will make your use of CMSH more enjoyable.

When we launched the Bright “Easy8” program and our BEACON user community in November last year, we took the unprecedented step of making Bright Cluster Manager free for clusters up to 8 nodes. This empowered organizations to reap the benefits of our mature commercial cluster management system at no charge.

To extract the most value from your HPC cluster, you need to ensure that system resources are being properly utilized.  HPC system users are notorious for over-requesting resources for their jobs, resulting in idle or underutilized resources that could otherwise be doing work for other jobs.  While one reason for this can be users hoarding resources to ensure they have what they need, another common reason why users over request resources is that they simply don’t know what resources their jobs will need to complete the job in a specified time.  For administrators to ensure that their precious and expensive cluster resources aren’t being squandered, they need to get actionable details regarding how the resources are being used.  More specifically, they need to know things like which jobs are using which resources, which jobs aren’t using resources that they’ve provisioned and which users are repeatedly hoarding resources unnecessarily, as well as other things.

A significant change we’ve seen in the HPC landscape is the need to process data and run workloads at the edge. Last year, Bright delivered Bright Edge, which allows organizations to quickly and easily provision and manage servers at edge locations and enabled them to manage multiple locations as a single cluster. The new year brings with it Bright 9.0, which provides the ability to deploy and manage a workload manager (WLM) instance at each location.

Auto-scaling HPC and Kubernetes

Bright CEO Bill Wagner’s recent blog post “The Convergence of HPC and A.I.” pointed out that creating HPC and Kubernetes silos within a shared HPC infrastructure is more like “coexistence than convergence”. The solution I will be highlighting  is Bright Auto-scaler, which automatically resizes HPC and Kubernetes clusters (workload engines) according to workload demand and configured policies. This post describes how to configure Bright Auto-scaler to achieve true convergence of HPC and A.I. through a scenario.