MindSphere Managed Backing Services¶
This section gives an overview of the included Backing Services. Each instance of a Backing Service runs on a dedicated virtual machine. These virtual machines and services are operated by MindSphere.
Available Backing Services¶
The following Backing Services are currently included:
| Backing Service | Description | Plan |
|---|---|---|
| MongoDB | MongoDB is a document data base that stores data in flexible, JSON-like documents, meaning fields can vary from document to document and data structure can be changed over time | mongodb-xs and mongodb-m |
| PostgreSQL | PostgreSQL is a powerful, open source object-relational database system. | postgresql-xs and postgresql-m |
| Redis | Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. | redis-xs and redis-m |
| RabbitMQ | RabbitMQ is the most widely deployed open source message broker. | rabbitmq-xs and rabbitmq-m |
| Elasticsearch | Elasticsearch is a distributed, RESTful search and analytics engine capable of solving a growing number of use cases. As the heart of the Elastic Stack, it centrally stores your data so you can discover the expected and uncover the unexpected. | elasticsearch-xs and elasticsearch-m |
| LogMe | LogMe allows to provision Elasticsearch, Logstash and Kibana, i.e. the ELK-stack. Simply bind your Cloud Foundry app to LogMe and it will automatically start collecting metrics and syslogs from your apps and services. | logme-xs and logme-m |
Service Plans¶
All service plans (*-xs and *-m) are enabled for every Org. Those plans are all marked as paid plans as you can buy additional instances of those. Depending on your offering a certain amount of concurrent instances is included. The following table lists those for the MindAccess Developer Plan:
| Offering | Concurrent instances included |
|---|---|
| Developer Plan S | 2 XS instances |
| Developer Plan M | 4 XS instances |
| Developer Plan L | 6 XS instances |
You can buy additional service instances in different sizes via the MindSphere Store. Therefore, the Cloud Foundry quota of your Org does not reflect allowed number of concurrent service instances.
Update to a larger Service Plan¶
Upgrade the service plan using the following command:
1 | cf update-service <serviceName> -p <largerPlanName> |
Disk Alerts¶
Every service instance is monitored by a Parachute component to evaluate the ephemeral and persistent disk usage. If a disk usage reaches the configured threshold Parachute stops all of this instance's processes and writes a message into the log directory:
Limit reached for: <persistent/ephemeral> disk
Restart Stopped Instances¶
The disk usage threshold for service instances is set to 80% by default. When restarting a stopped service instance, the threshold can be configured using the max_disk_threshold parameter. It accepts integer values between 0 and 100. The following sample shows how to restart a service instance with a threshold of 90%:
1 | cf update-service <serviceName> -c '{"max_disk_threshold": "90"}'
|
Restarting the service instance takes a few minutes.
Attention
This is only a temporary solution. The service instance is stopped when the threshold is reached again. For a long-term solution, the service instance must be updated to a larger plan size if available.
Sharing Service Instances¶
Sharing a service instance between spaces allows apps in different spaces to use the same instance of a MindSphere managed backing service. This eliminates the need to use service keys and user-provided services to bind apps to the same service instance.
Refer to the Cloud Foundry documentation about sharing instances for further details.
Features¶
- Service instances can be shared among multiple spaces within one Cloud Foundry org.
- Sharing service instances among spaces requires the Space Developer role in these spaces.
- Service instances can be bound or unbound in spaces it is shared with, but cannot updated, renamed or deleted.
- Configuration parameters used for provisioning or updating the service instance can be read from all spaces the instance is shared with.
- Sharing a service instance to another space does not decrease the remaining service count quota of your org.
- Shared service instances only count as one instance in the service count quota of your org.
Example scenario¶
Consider two development teams who deployed apps in their own spaces. Their apps shall communicate using a messaging queue.
- The development team in space A creates a RabbitMQ service instance, binds it to their app, and shares the service instance with space B.
- The development team in space B binds their app to the same service instance and the apps can begin to communicate.
Refer to the How Tos for instructions.
Backing Service Documentation¶
Any questions left?
Except where otherwise noted, content on this site is licensed under the MindSphere Development License Agreement.