Multitenancy Best Practices - padogrid/padogrid GitHub Wiki

◀️ Multitenancy :link: PadoGrid-Configuration-Files ▶️

Managing multi-tenant workspaces requires strict compliance with well-defined guidelines. This section provides best practices that you can apply in creating guidelines that may apply to your company.

  1. Create workspace sandboxes. When you create a new workspace, remember that your primary task is to create a sandbox that completely isolates the new workspace from other workspaces. This means user permissions must be carefully set at the owner and group levels such that only the users belonging to the group may have access to the workspace. Follow the instructions provided in the Multitenancy section.

  2. Create a single user workspace whenever possible. Having a single user per workspace simplifies the workspace management and eliminates user conflicts. A single user is analogous to a service account. To create a single user workspace, create a group that has only one user and set ACL permissions for that group to the workspace.

  3. If you must create a multi-user workspace then make sure the users are aware of the following restrictions and limitations.

    1. Create a service account. All long running processes must be managed using the service account. Only select users in the group may have access to this account.
    2. Processes may be killed only by the user who started them. This means, for other users to stop the processes, there must be a shutdown command that gracefully stops the processes without using the kill command. For example, PadoGrid's kill_cluster will only work for the user who ran start_cluster. For all other users, the shutdown_cluster command, which does not use kill, must be used instead. For this reason, all long running processes should be managed by the service account.
    3. If a user creates a new file, then that user remains the owner of the file. The file maybe modified by other users, but the owner of the file will not change.
    4. Since multiple users are accessing the workspace, it is expected that there will eventually be files belonging to different owners scattered in the workspace. To miminize the user conflicts, consider organizing the workspace by desginating a directory for each user where they can keep their artifacts.

  4. Bring Your Own Resources (BYOR). Let the users bring their own system resources. Instead of locking users into hardware provided by you, let them bring their own. This not only frees up your maintenance tasks, but allows the users to freely scale out at their choosing. For example, a workspace may attach AWS EC2 instances that the users allocated. To manage such workspaces, you would create a VM-enabled workspace and follow the normal procedure of applying the ACL permissions to the workspace.

  5. Create mount points. You can host a vast number of workspaces on a single machine by adding mount points. For example, you can have multiple mount points and spread workspaces them, or create an RWE on a separate mount point. Remember that PadoGrid stores only application artifacts in each workspace and each workspace's artifacts dictate what hardware and software to use. A workspace could be using the workspace host machine's resources, cloud resources, Kubernetes, Docker, etc.

  6. RAID Storage and Backup. As with any enterprise systems, the workspaces should be on redundant storage and a backup strategy should be in place in case of catastrophic failures.

  7. Start small and scale out. PadoGrid can scale out by assigning a set of workspaces per host, dedicating an RWE per host, maintaining the entire workspaces on shared mount points with a load balancer on top, and etc. You should always implement the simplest approach if possible to avoid the maintenance complexity. Because you can distribute workspaces, you can start small and easily scale out from there.

◀️ Multitenancy :link: PadoGrid-Configuration-Files ▶️