Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

It is also recommended to work with your assigned Solution Architects and the DataCore Support teams as part of upgrade planning. They can review your service requirements and help identify areas where you may need to perform actions such as customer notifications for service maintenance, where you may encounter pain points in the process depending on the amount of data you have under management coupled with client activity, and other criteria of note.

Service Silos (“Divide and Conquer”)

As mentioned near the beginning of this document, you may encounter a situation where it’s effectively impossible to reconcile the needs of different workloads & workflows in a single DataCore Swarm deployment. For example, you may have conflicting customer activity (a.k.a. “the noisy neighbor” problem) which can’t be addressed with single stack tuning.

It’s possible in such situations to deploy multiple Swarm stacks within your back end service to split such activity out. Note that our strategy thus far has been to route customers to their appropriate path through front end load balancer evaluation, which then routes the customer through their designated Gateway pool and ultimately to their back end storage target. A comprehensive and robust load balancer solutions will scale well in handling these “host header” level evaluation decisions, allowing you to set up the necessary segregated Swarm stacks to split up work.

As the service scales to a large pool of customers with diverse requirements, setting up different Swarm pools on the back end will allow you to scale out in addition to scaling vertically within single Swarm installs. Naturally, this will have ramifications in the following key areas:

  • License Management - each Swarm deployment will need its own license

  • Hardware Sizing - each of the deployments will need to be properly designed for the anticipated work that will be re-routed to it from the original cluster

  • Data Migration - moving of the “noisy” customer’s data from the original deployment to the new deployment

As outlined before, capacity monitoring and planning along with an eye on overall Swarm load will provide indicators for when such work may prove necessary.