GoTo PartnerCloud Inception

Reason to deploy a  cloud native deployment

• 1 Click deployment of EF-CX tenant

Bigger Picture

External components for-example mongo, minio, redis and postgreSQL are deployed using replication while using the local disk as  the storage mechanism.

Sign-Up

A user signs up form  with 

• username

• Password

• email

and is returned with a customer ID

Process 

The user given a progress bar which will run below given schedulers at the backend.

• region

• namespaced EF-CX deployment 

• instantiation of 

  • tenant ID in KeyCloak

    • with central postgreSQL DB 

      • running in pgpool env with

        • a minimum of 1K connections available

        • PV size of 250 GiB

  • mongo

    • Option-1 

      • 1 single MongoDB cluster ( 1 master, all else slaves )

      • consistency 

        • 1 master always available

        • DR can survive upto 1 node in the whole cluster

      • average size of the customer data

      • retention of the customer's data

      • retention policy

      • management is expensive

      • administration is hectice

      • single point of failure

      • easy to setup with Local-Volume based storage ( no need for a Cloud native Storage ) 

      • Backup and restores are 

        • overall performance 

        • restoration of the cluster may take time.

    • Option-2

      • 1 single instance per Tenant ( Using MongoDB operator )

      • Requires Cloud Enabled Storage ( longhorn, OpenEBS  or Rook )

      • manageability

      • administration ( more sort of automated administration is handy with operator style )

      • backups and restoration is easy

  • redis

    • Option-1

      • Redis Operator based deployment

      • independently covered and managed

      • requires Cloud Native Storage ( Longhorn, OpenEBS or Rook ) ( another option is to use local-disk of the node as always )

      • performance degradations covered because another client may have messed up the their own redis instnace.

      • Backup/recovery-- do we really need to backup redis data PV ??? discuss 

      • Node Failures are covered when 

        • Node where the redis instance was running, fails, the cluster spins up the same instance on another available node with possibilities of 

          • if using local storage – the re-birth will be flash blank

          • if using Cloud native – will emerge from where it crashed.

    • Option -2

      • Deploy as a Redis Cluster ( possibly with Centinel ) 

      • One Central EndPoint for the whole cluster

      • Requires at least 5 nodes ( a minimum of 3 , but recommended 5 )

      • One large database ( with centinel only 1 large database is possible ) but solution is guarentee to run 

      • Node failure survivals  

        • can survive until last node

      • Backup/restore – discuss

    • Option-3

      • Deployed as 1 Master with 1 Slave approach

      • Can be either per tenant or Central

      • Supports multiple database

      • can be namespaced ( local to tenant ) 

      • requies at least 2 nodes

    • Option-4

      • 1 single instance of the redis will be enough ( manually driven )

  • ActiveMQ/Artemis in a central Pool

    • preferred single instance per tenant