Managed Fusion is similar to self-hosted Fusion in terms of supported features and capabilities, but differs when it comes to day-to-day operations and change promotion procedures.
This section details the differences between the two offerings.
What are the differences between self-hosted Fusion and Managed Fusion?
In self-hosted Fusion, you host and manage your own Fusion deployment. In Managed Fusion, Lucidworks handles the backend operations, promotes changes, and performs updates.
Some features are only available in self-hosted or Managed Fusion. See Managed Fusion versus Fusion.
Why are some features only available in self-hosted Fusion and not Managed Fusion?
Some features, like custom Docker images and custom stages are not supported in Managed Fusion.
Limiting the amount of custom configurations in Managed Fusion helps to ensure uptime and improves customer support.
Limiting custom components also helps to streamline the upgrade process and simplifies troubleshooting.
Can I migrate to Managed Fusion from self-hosted Fusion?
Yes, you can migrate from any self-hosted Fusion version to Managed Fusion. Lucidworks Professional Services can assist with the migration. For more information, contact your Client Success Representative.
How do the day-to-day operations change when moving from self-hosted to Managed Fusion?
In a Managed Fusion deployment, there are different environments used for development, staging, and production.
You make changes in a development environment, perform tests in a staging environment, and create promotion requests to apply those changes to a production environment.
Lucidworks reviews promotion requests and publishes your changes to production within three (3) business days of the request.
For more information, see Promotion to production.
What is a typical Managed Fusion multi-region Solr deployment?
Managed Fusion uses a Four 9s (99.99%) availability architecture with primary and secondary clusters.In a 4 9s deployment, Region A hosts the primary (“hot”) cluster responsible for real-time data indexing and query processing, while Region B hosts the secondary (“warm”) cluster, acting as a backup for historical data and disaster recovery.
The primary and secondary clusters are automatically kept in sync for proper failover in case the primary cluster becomes unavailable.
The number and type of environments you have depends on your setup and agreement. The typical setup includes three environments: Development, Staging, and Production. See Managed Fusion environments.
Lucidworks restricts access to production environments to guarantee client SLAs and provide confidence of uptime.
Managed Fusion is highly configurable.
Guardrails enable uptime and success, and business rules allow modifications while minimizing the risk of errors, failure, and downtime.
You can test and promote changes per the process outlined in Promotion to Production.
What if I need to promote a change sooner than the three day SLA?
Lucidworks will evaluate the request but cannot commit to timelines outside of the SLA.
If you require a shorter turnaround time for promotions requests, contact your Lucidworks Client Success representative.
How are code changes promoted so that multiple clusters are upgraded without downtime?
Because clusters have their own config sync branches, Lucidworks promotes the code changes to any or all clusters depending on your needs.
For more information, see promotion requests for 4 9s clients.
The data is available through Grafana. You can request the link and credentials to your Managed Fusion Grafana Dashboard from your Client Success Representative.
The data is available through Grafana. You can request the link and credentials to your Managed Fusion Grafana Dashboard from your Client Success Representative.
These logs contain information about Solr cores, nodes, and overall system performance.