Growth Beyond Minimum Viable Platform
Page last updated:
Organic growth from MVP1 is expected and encouraged. The next sections will offer considerations on growing from a lower to a higher level of fault tolerant architecture progressively.
Key items that change are:
- Two more racks are added to the original. making three racks
- Each rack represents a vSAN fault domain and vSphere Host Group, equivalent to a PCF availability zone
- Management functions do not change location
- The maximum number of hosts per installation is limited to 64 due to vSAN Cluster limitation
Migration from the original rack to using the added racks is possible with PCF by modifying vSphere host group definition and performing a bosh recreate. The PaaS will deploy all components that can be deployed as multiples will be into equal distributions across both AZs (as long as multiples selected are evenly divisible by the number of AZs used)..
Repaving is a good choice at this stage, as it will place the singleton and multiple element components in the correct locations.
This design is considered production-ready with ample high availability and redundancy capacity for full-time enterprise use. This size is appropriate for combined Enterprise PKS and PAS deployments combined, if desired, using Resource Pools to organize components of each into the clusters.
Key items that change at this point in growth:
- A total of four clusters are deployed: one for management of the whole system and three for payloads generated by the system.
- All management functions are focused onto a single cluster of six hosts with vSAN. The remaining three clusters are AZs for PCF product(s) and for payload (app) use only.
- All PaaS components that deploy in multiples are deployed in triples to take advantage of the multiple availability zones. HA features of both the IaaS and PaaS are brought to bear on the AZs.
Migration from the starter kit may be a challenge, as all management VMs from vSphere, NSX-T Data Center and Pivotal will be migrated to a dedicated cluster and not blended in with any of the app containers created by Enterprise PKS and/or PAS.
A fresh install of the PaaS layer makes this model the easiest to install.
Repave is a good choice at this stage, as it will give the opportunity to place management components in the proper cluster and evacuate any pre-existing clusters of anything other than payload (app) components.