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. If you need additional help understanding the differences between them, we offer a comparison hosting tiers table highlighting key distinctions.
Last updated on
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 in 30 continuous days. Review types of application 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 CITZIMBSD@gov.bc.ca to submit a request.
Gold hosting tier
The Gold hosting tier is recommended for business mission critical government services who require a geographic failover for their applications or want to take advantage of the delayed upgrade cycle explained in the maintenance schedule.
The Gold Hosting Tier consists of two OpenShift clusters:
- Gold cluster, located in the Kamloops government data center
- Gold Disaster Recovery (DR) cluster, located in the Calgary data center
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% in 30 continuous days, specifically for applications with multi-node deployments that have a geographic failover to the Gold DR cluster in the Calgary data centre, minimizing disruption. Without DR, Gold maintains the same availability as Silver. Review types of application deployments.
Configuring your applications for geographic failure is a requirement in the Gold hosting tier.
Teams will be allowed to migrate their applications to Gold without an immediate plan for implementing DR failover.
More information on using the Gold cluster without DR.
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 CITZIMBSD@gov.bc.ca 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 in 30 continuous days. Review types of application 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 CITZIMBSD@gov.bc.ca 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 by emailing PlatformServicesTeam@gov.bc.ca. 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.
- Shut down all the running components from the old project set and ensure that there’s no persistent data remaining
- Go to Platform Product Registry and delete the old project set