Single-instance sharded deployment

A single-instance, sharded deployment is another version of a single-instance deployment, but with multiple database shards.

In this type of deployment, an enterprise is associated to a single colony. The colony for an enterprise can be different from that of another enterprise. Each enterprise shares a common Configuration shard, Statistics shard, and Metadata shard, but it can have its own dedicated Master shard or can share a Master shard with other enterprises. In addition, each enterprise can have its own dedicated Transaction shard or it can have multiple Transaction shards associated with it. A colony can be identified using Enterprise Code, Seller Organization Code, or any custom attributes.

IBM® Sterling Selling and Fulfillment Foundation supports the following types of single-instance, sharded deployments:

Note: Configuration of promising server is required for implementing multi-tenancy and you may have to configure the promising server for both sharding by enterprise and sharding by seller. However, promising server doesn't support work orders, and hence work orders are not supported in a multi-tenancy environment.

Following are the advantages and limitations of these sharded deployment options.

Advantages

  • Central point of control because it is a single-instance deployment.
  • You can run one agent server that will process data across colonies. For example, you can run the Order Monitor enterprise agent to process data for an enterprise and its stores. If the enterprise’s stores are located in different colonies, multiple threads will be spawned to process the data.
  • You do not need to synchronize Configuration data, such as hub-level pipelines, that is shared by two colonies.
  • Colonies can upgrade independently. However, if an enterprise that was inheriting rules from another enterprise is upgrading, the Configuration shard of both enterprises needs to be upgraded. If an enterprise upgrades, its participating organizations should also upgrade. These include nodes, capacity organization, catalog organization, and so on.
  • Enterprises in different colonies can share the same Configuration shard, but because they are in different colonies, they can still be upgraded independently.
  • Enterprises in different shards can inherit rules from a common organization.
  • Two different Transaction shards can inherit some configuration rules.
  • As data increases within a shard, you can further improve scalability by diverting data to a new shard.
  • Compared to a single-instance, nonsharded deployment, you can keep adding database shards for scalability.
  • Enterprises can benefit from the isolated Configuration shard when using the Configuration Deployment Tool (CDT), and at the same time, be able to deploy Configuration data across multiple colonies.

Limitations

  • Cross-version data synchronization capabilities for the user interface are not supported. For example, if a Retailer deployment is running on a different version from a Web deployment, you cannot synchronize the data between these two clusters of application servers.
  • Resharding is not supported.
  • Sharding is not supported when inventory and availability-related configuration and information is maintained internally; it is only supported when inventory and availability-related configuration and information is maintained in a Promising server, which is deployed externally.
  • Sharding is limited to enterprise-level sharding for the following:
    • Invoices
    • Workorders and associating workorders to an order
    • Receipts
    • Loads
  • Enterprises that belong to different colonies cannot share capacity.
  • In the Configuration Deployment Tool (CDT), you can compare and migrate Configuration data all at once. But to migrate Master data, you must point the CDT to each colony and migrate on a per-colony basis.
Parent topic: Flexible order management deployment configuration options
Related information:
Introduction to sharding
Using configuration organizations