Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
2.6. Object Storage
- Composite Tokens and Service Accounts
- Previously, data was stored in either a dedicated service account (single project) or in the end-user's account (multi project). If data was stored in the service account, there could be issues with container or service-user deletion, and passwords and tokens were fragile. If data was stored in the end-user account, issues arose if the user picked the same name as the service, and the Object Storage service had to deal with users violating the integrity of tokens.To solve these issues:
- Object Storage now stores service data in a separate account to the end-user's 'normal' account, but which is still linked to the end-user's project for accounting purposes. Access to the service account is managed by composite tokens.
- Composite tokens have been introduced. Composite tokens use two authentication tokens when storing data: one from the Object Storage service and one from the end user. Once the two tokens are set, the data cannot be changed without consent from both service and user. This protects data from being deleted by the end user without some kind of administrative process, and prohibits the service from making decisions on behalf of the user.
- Efficient Replication for Globally Distributed Clusters
- Previously, in globally distributed clusters, replicas were pushed out to each node in each region. With this update, the Object Storage service now only pushes replicas to just one remote node in each region (based on affinity); the remote node then spreads the replica out to primary nodes in the same region. By reducing the amount of data transfer between regions, this update stabilizes performance and lowers both the chance of replication delays as well as the cost of data transfers.