(4) Create a design doc for distributed multi-tenant storage

[zbbhangzhi]

Multi-tenant and Distributed database V1.0

Multi-tenant environments share the same system or program components and can ensure data isolation between users.

High-Level architecture

Function

• Multi-tenant shared platform: compute, storage, network
• Data isolation between tenants
• Support for organization-based management within the tenant, with the ability to authorize and manage storage strategy.

User Model

• tenant
• user
• permission

Tenant Isolation Model

Isolation of the storage, network, and other resources involved in the underlying layer

• Hybrid mode

  User-selected: Shared mode (base domain) or Shaft isolation mode (dedicated domain)

  • Shared model: small and medium-sized clients

    • Multiple tenants sharing the same set of infrastructure resources

  • Advantages

    • Efficient management, with all tenants centrally managed; simple infrastructure configuration and faster product iterations
    • Lower cost, dynamic scaling of the system according to the actual load of all tenants, very high infrastructure utilisation

  • Disadvantages

    • Tenants affect each other, when one tenant takes up a lot of machine resources, the experience of other tenants is affected (restrictions such as flow limitation, downgrading, server isolation need to be added to the architecture)
    • Difficulty in billing
    • Data management woes: difficult to delete if tenants do not renew; difficult to recover data in case of failure, which affects other tenants

  • Single data source single database single data table: there is only one database, all tenants share the same data table; each table has an extra column for the tenant ID, each time the tenant ID is added, deleted and checked

  • Shaft model: large customers

  • Each tenant runs in an isolated set of resources, with its own separate set of end-to-end infrastructure

  • Advantages：

    • Strong isolation, safety; low impact of faults
    • Easy billing logic

  • Disadvantages：

    • Difficult to scale up: not easy to manage if the number of tenants reaches thousands

    • High cost of ownership, weakening profitability

    • Agile iteration capabilities hampered

    • In this decentralised model, the management and monitoring of each tenant's infrastructure is very complex

    • Multiple data sources, multiple databases, multiple data tables

    After the project starts, the datasource information for all tenants is loaded from the database based on the tenant ID, created and injected into the container; if a tenant goes online or offline, a configuration listener is added to dynamically add and remove datasources.

Distributed Storage

Centerless architecture: Consistent hashing

Omit the namenode and deploy it as a stateless service that can be clustered to deploy apportioned requests.

Core scenes

• Intra-tenant model relationships
  • Create secondary organisations, add people and give roles within the tenant
  • Ordinary users join the business system to request or use resources
• Tenant Identification: Tenants bring their tenant information with them when they request
• Tenant billing and metering management
  • Shaft pattern
  • Shared mode: combined billing based on data such as request concurrency, storage capacity, number of data objects, etc.
• Dynamic Capacity Expansion
• Data replication
  • Raft algorithm: each data change is landed as a Raft log, which is safely and securely synchronised to multiple nodes in the replication group through Raft's log replication function
• Failed data recovery
• Request flow limiting: Limits based on time windows for ingestion and select requests to avoid overuse of resources and performance degradation

Extension issues

• Tenant Network Isolation
  • Assign the corresponding VPC and subnet when creating the tenant object