Object Store service offers standard cloud foundry service broker lifecycle operations. We refer to them as control plane operations. These include create-service, delete-service, bind-service, unbind-service, create-service-key, delete-service-key, and update-service. The create-service and delete service operations help in provisioning and deprovisioning of storage resources. The bind-service and create-service-key operations help in getting access credentials with other parameters in order to perform various operations on the provisioned object store resource. The unbind-service and delete-service-key operations help in invalidating the credentials that are generated as part of the bind-service/create-service-key operations. The update-service operation helps in making configuration-related changes on the existing service instance and the corresponding resource.
Object Store service helps in provisioning resources and generating access credentials for users to directly access the underlying object store (AWS S3 buckets, Azure Blob container, or Google Cloud Storage buckets). It doesn't act as an interface for performing any kind of operations by users.
All the buckets created by the service are created in the standard storage class only. The other storage classes like infrequent tier, glacier etc. aren't supported.
Object Store service creates buckets/containers in the same region as the underlying infrastructure. For example, if the "objectstore" service instances are created in a subaccount that belongs to say AWS Frankfurt region, then the bucket is also created in the same region.
Usage Analytics pages in the Cockpit provide a view of aggregated usage at various levels:
All the supported infrastructures provide storage solutions that are secure by default. Object Store service together with the underlying infrastructure ensures user authentication and authorization to control access to data. It enables access to buckets or containers by creating technical users, assigning limited set of permissions, and sharing corresponding credentials through service instance bindings or service keys. For more details on credentials, you can refer to the Object Store service's IaaS specific documentation.
|
Infrastructure |
SSL Configuration |
|---|---|
|
AWS |
Support only HTTPS |
|
Azure |
Support only HTTPS |
|
GCP |
Support both HTTP and HTTPS |
For the GCP infrastructure, we recommend that you use HTTPS. By default, gsutil makes use of HTTPS. But, if you are using any other way to store and access objects, see the documentation of the Google Cloud Platform, gsutil tool.
SAP doesn't perform data event logging on buckets created through SAP CP Object Store service. However, note that on AWS, SAP supports "server access logging" feature of AWS S3, that can be used to capture logs of data events. For more details, refer Server Access Logging topic.
Object Store service enables customers to use various supported hyperscaler's object store offerings. It enables only the features the underlying hyperscalers already support. Therefore, there's no backup and restore feature provided by SAP Object Store service.
However, the objects are replicated across multiple availability zones within a region for high durability. The respective hyperscaler internally ensures that the objects are available even if an entire availability zone becomes unavailable. For more detail on the replication, see the Object Store service’s documentation for different IaaSes.
There are additional features that could also help in backup and restore in certain scenarios. For example, if there any objects are accidentally deleted, we recommend you to use the features like object versioning and expiration rules. Enabling versioning allows you to recover from accidental deletion and modification of objects because the hyperscalers keep older versions in case the objects are modified or deleted. In addition, setting expiration rules helps in automatic deletion of older versions. See the respective hyperscaler documentation of Object Store service for more details to learn about these features and to understand how these features could be used.
Also, if you want to prevent your blob stores from accidental deletion, prevent deletion feature is available. If you enable prevent deletion on your object store instance, Object Store service doesn’t delete the service instance, and hence the corresponding blob store, if there are one or more objects present within. In other words, having the flag enabled on your object store instance would prevent deletion of instances for nonempty buckets. It helps prevent any accidental deletion of an object store instance. For more information on default configurations and the recommendations, seeBackup and Restore .