Home › Cloud › Private cloud › Products and tools › Hosting tiers

Hosting tiers

The B.C. Government Private Cloud Platform as a Service (PaaS) is powered by RedHat OpenShift containerization software. Explore our 3 OpenShift hosting tiers: Silver, Gold and Emerald.

The Private Cloud team will help teams choose the best tier option based on their needs and the required security controls.

Silver hosting tier

The Silver hosting tier is suitable for most government services and meets the requirements for hosting information up to and including Protected B classification. It offers application and data hosting for cloud-native applications in the platform’s Silver OpenShift cluster in the B.C. government’s Kamloops data centre.

Maintenance schedule

All upgrades and patches to the Silver hosting tier are first tested in sandbox clusters in the Kamloops data centre and Calgary data centre. Afterwards, they’re applied to the Silver hosting tier cluster. 

Availability

Platform availability for the Silver hosting tier is 90% for single-node application deployments and 99.5% for multi-node deployments. 

Network service

The Silver cluster implements standard OpenShift routing.

Product teams are required to bring Custom TLS certificates with their application. Custom TLS certificates can be requested through the iStore. Email IMB Service Desk to submit a request.

Gold hosting tier

The Gold hosting tier should only be used by experienced DevOps teams who require a geographic failover for their applications. It’s recommended for business mission critical government services.

This tier includes application and data hosting for cloud-native applications in the Gold OpenShift cluster in the Kamloops data centre. You must also set up application failover to the Gold Calgary OpenShift cluster in the B.C. government’s Calgary data centre.

The Gold hosting tier meets the requirements for hosting information up to and including Protected B classification.

Maintenance schedule

All upgrades and patches are first applied to the Silver hosting tier and undergo a one-week testing period in the Silver cluster. If no issues are identified after one week, the changes are applied to the Gold hosting tier clusters.

Availability

Platform availability for the Gold hosting tier is 99.95% for applications with multi-node deployments that have a geographic failover to the Gold Calgary cluster in the Calgary data centre. 

Configuring your applications for geographic failure is a requirement in the Gold hosting tier.

Network service

The Silver cluster implements standard OpenShift routing and non-HTTP traffic to support application data replication between Gold Kamloops and Gold Calgary clusters.

Product teams are required to bring Custom TLS certificates with their application. A global server load balancer (GSLB) service must be requested for the geographic failover. Both services can be requested through the iStore. Email IMB Service Desk to submit a request.

Emerald hosting tier

The Emerald hosting tier supports integration between OpenShift and Virtual Machines (VM) through the new Software Defined Networking (SDN) technology. This capability will make it easier to modernize existing applications using an incremental approach.

For applications that are handling Protected C information, the Emerald cluster has additional security features that aren’t available in Silver or Gold.

Maintenance schedule

Upgrades to the Emerald hosting tier are based on NSX compatibility with OpenShift. Review the “Guide for Emerald teams” in the IDIR protected content section for more details.

Availability

Platform availability for the Emerald hosting tier is 90% for single-node application deployments and 99.5% for multi-node deployments. 

Building integrations with non-Openshift components or working with Protected C data is a requirement in the Emerald hosting tier.

Network service

Access to the Openshift Console for the Emerald cluster is only accessible via VPN or when on a government wi-fi network (such as BCNGN.)

Workload tagging/labelling based on security classification level (high, medium, low) is supported in this tier which allows defining network security rules based on component security levels.

Product teams are required to bring Custom TLS certificates with their application. Custom TLS certificates can be requested through the iStore. Email IMB Service Desk to submit a request.

How to migrate between clusters

Learn how to start the migration between different OpenShift clusters. If you have specific infrastructure needs that your current cluster can’t fulfill, follow these steps.

Step 1: Attend a migration assessment meeting

Request an assessment meeting. During this meeting with the Platform Services team, you’ll receive an overview of topics such as:

  • The specific infrastructure needs from a different OpenShift cluster
  • Which OpenShift cluster would be the best option
  • An assessment on your team and application to determine if you’re ready to move towards a higher hosting tier 
  • Migration timelines and follow-up actions
  • Responsibilities as a product team working on a different cluster

Step 2: Set up your access to the new OpenShift cluster

Once the assessment meeting is completed and your team is ready, you can start a new project set request at Product Registry.

In the request, ensure:

  • That the new project set name matches with the old one
  • You’ve picked the OpenShift cluster previously discussed is the assessment meeting
  • Your new project set will start with a small quota set, by default
  • That if you’ve successfully requested a quota increase in your current project set already, that it’s mentioned in the new quota request once the new project set is ready

Gold and GoldDR clusters share the same authentication process as Silver. If you’re migrating to Emerald, BCGOV VPN access is required.

Step 3: Migrate applications

The migration path and requirements are different based on the type of cluster. The Platform Services team provides the OpenShift cluster platform infrastructure and the shared services, but you are responsible for updating the application to work on the new clusters.

For example, the Gold cluster comes with a Disaster Recovery cluster, as does GoldDR. The 2 clusters are geo-redundant, when a cluster wide incident happens on Gold, traffic to applications will be automatically redirected to GoldDR by the GSLB. However, you need to design the DR strategy for your application and set them up so that your workloads can benefit from the cluster failover to achieve better service availability.

There is detailed documentation and how-to guides about working on different OpenShift clusters in the IDIR protected content. You are highly encouraged to use the information to modify your application for the migration.

Make sure to also migrate your DevOps components, including but not limited to:

  • CICD pipeline
  • Database backup
  • TLS cronjob

To prevent any persistent data loss during the migration, review our recovery guide before starting.

Step 4: Retire workloads remaining from the old cluster

After you’ve successfully migrated application workloads and DevOps components in the new OpenShift cluster, it’s time to retire the old project set.

  1. Shut down all the running components from the old project set and ensure that there’s no persistent data remaining
  2. Go to Product Registry Service and delete the old project set