# Regarding Cross cluster replication
**URL:** https://discuss.elastic.co/t/regarding-cross-cluster-replication/372349
**Category:** SIEM
**Created:** [December 24, 2024, 7:28am UTC](https://discuss.elastic.co/t/regarding-cross-cluster-replication/372349 "2024-12-24T07:28:47Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@mike123](https://discuss.elastic.co/u/mike123)
#### Post date: [December 24, 2024, 7:28am UTC](https://discuss.elastic.co/t/regarding-cross-cluster-replication/372349/1 "2024-12-24T07:28:47Z")
I am having a ES cluster with Fleet server, Kibana and elastic-agents. I want to create a DR (Disaster recovery ) setup for it. I am running alerts and ML rules with Elastic Defent in this setup. If i go for bi directional cross cluster replication, The setup will be like below
DC1 has its own kibana, fleet and elastic-agents installed in DC1 servers and DC2(DR DC) must have its own fleet and elastic-agents installed in DC2 servers. In this case i have to configure rules and alerts in two DCs separately. Is there any way to avoid this and handle both DCs using a single kibana?
Or is there any other suggested way to setup DR fleet server?
---
### Author:  [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)
#### Post date: [December 24, 2024, 1:04pm UTC](https://discuss.elastic.co/t/regarding-cross-cluster-replication/372349/2 "2024-12-24T13:04:20Z")
> [@mike123](#):
>
> Is there any way to avoid this and handle both DCs using a single kibana?
I don't think so, each Kibana can be connected to only one cluster, so you would need one kibana for each server.
> [@mike123](#):
>
> Or is there any other suggested way to setup DR fleet server?
Not sure what you mean with DR for feet server, it does not support it.
Each agent can be managed by only one Fleet Server, so if you have agents being managed by a Fleet Server in your DC1, and your Fleet server in DC1 is offline, you will not be able to manage these agents until the Fleet Server is back online.
If you want to have a bi-directional ccr you will need what you already said, replicate the same rules and alerts in both clusters.
---
### Author:  [@mike123](https://discuss.elastic.co/u/mike123)
#### Post date: [December 24, 2024, 1:18pm UTC](https://discuss.elastic.co/t/regarding-cross-cluster-replication/372349/3 "2024-12-24T13:18:21Z")
Thanks for your response.
This is a dumb question but still wish to confirm it...will it be possible to replicate the .fleet index (which stores the data about fleet server) to another cluster?
Is there any way to sync rules from one cluster to another?
---
### Author:  [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)
#### Post date: [December 24, 2024, 1:38pm UTC](https://discuss.elastic.co/t/regarding-cross-cluster-replication/372349/4 "2024-12-24T13:38:29Z")
> [@mike123](#):
>
> This is a dumb question but still wish to confirm it...will it be possible to replicate the .fleet index (which stores the data about fleet server) to another cluster?
I don't think so, not everything that fleet uses is stored on those indices, you would need a snapshot of the fleet feature state, and to restore it in another cluster, which would override the agents you have there.
But there is no documentation about it, the only similar documentation that exists is about migrating agents between clusters and the only way to do that is to re-enroll the agent in the new cluster.
> [@mike123](#):
>
> Is there any way to sync rules from one cluster to another?
There is nothing built-in for that, but everything uses an API, you could use the detection rules API to built an export/import flow to replicate your rules.
---
### Author:  [@stephenb](https://discuss.elastic.co/u/stephenb)
#### Post date: [December 24, 2024, 6:24pm UTC](https://discuss.elastic.co/t/regarding-cross-cluster-replication/372349/5 "2024-12-24T18:24:45Z")
> [@leandrojmp](#):
>
> > [@mike123](#):
> >
> > This is a dumb question but still wish to confirm it...will it be possible to replicate the .fleet index (which stores the data about fleet server) to another cluster?
>
> I don't think so, not everything that fleet uses is stored on those indices, you would need a snapshot of the fleet feature state, and to restore it in another cluster, which would override the agents you have there.
Hi @mike123 and @leandrojmp
Today "Multi-Cluster Fleet is not supported" it is something that has been discussed and in the planning phases, it is a much requested feature so we want to get it right. No ETA for delivery (not to mention that elastic does not pre-announce feature releases)
But there is an Issue you can follow:
>
>
> A globally distributed enterprise that operates in many regions will by definiti…on have many data sources spread across these regions. Naturally they will be collecting and storing the data in clusters local to those regions. However when it comes to analysis of that data for Security and Observability, they would rely heavily on cross cluster technologies so that the collected data is seen and operated on singularly (as though they are in a local cluster).
>
> Fleet users, with Elastic Agents deployed in many such regions currently don't have the ability to easily manage their deployment at a global level yet reap the benefits of having their data stored and handled locally. This issue is to track all the requirements for enabling Fleet in a multi-cluster deployment. The goal is to facilitate the deployment of Fleet in a manner shown below:
>
> !\[image\](https://github.com/elastic/kibana/assets/13442829/cffd6ade-9366-4422-8e95-55068a4ffaa3)
>
> \# In this deployment model:
> 1. Elastic Agent check-ins are sent to the Management Cluster, where \`.fleet\*\` system indices are built. This will provide \*\*Global Control\*\* via Fleet in the Management Cluster.
> 2. By utilizing Cross Cluster Search (CCS) dashboards can be built using datastreams from all the remote clusters, thereby providing \*\*Global Visibility\*\*.
> 3. With a \*\*Local Data Plane\*\*, Integrations Data ingested by the Elastic Agents is stored at the local cluster, avoiding any extra cross regional egress charges and more importantly abiding by local data sovereignty rules.
>
> \# In this model how do we perform:
> \*\*(1) Agent Upgrade\*\*
> \- The global Fleet UI enables the user to issue the upgrade command.
> \- Actions are curated by the local Fleet Server and sent to individual agents.
> \- Agents then reach out directly to the configured repo to get their artifacts.
>
> \*\*(2) Adding Integrations to the Agent Policy\*\*
>
> \- Integrations are added to the policy at the global Fleet level.
> \- Policy will then be curated and utilizing the Fleet Server, it’s distributed to all agents
> \- Agents will enable the input based on that integration
> \- NOTE: local cluster will not install assets and ingest pipelines, this will be an enhancement
>
> \*\*(3) Build user dashboards\*\*
>
> \- Utilize CCS to query the datastreams of interest and build user dashboards
> \- Users for the most part can perform this step directly. Can it be optimized?
>
> \*\*(4) OSquery\*\*
>
> \- The query is issued via .fleet-actions and the response from the query is read from .fleet-actions-results.
> \- If these indices are available in the management cluster then the operator should be able to perform an OSquery
>
>
> \`\`\`\[tasklist\]
> \### Requirements
> \- \[\] Dataviews to be dynamically modified based on the set of clusters nominated so make the operation of this type of deployment easier.
> \- \[\] Fleet UI to show which clusters agents are writing data to. Perhaps as a separate/new column (or customizable columns where the user would add the information they are interested in). Allowing for filtering and better UX for users to quickly identify agents in remote clusters.
> \- \[\] User should be able to nominate which clusters are members of a multi-site deployment.
> \- \[\] Fleet UI allows filtering based on the cluster.
> \- \[\] https://github.com/elastic/kibana/issues/187323
> \`\`\`
>
> \### Implementation plan
> \- \[x\] #192339
> \- \[x\] #192340
> \- \[\] https://github.com/elastic/kibana/issues/187323
> \- \[\] https://github.com/elastic/ingest-dev/issues/3939
> \- \[\] Support feature to opt in for CCS in integration assets (M/L)
> - Add setting to remote ES output to opt in for CCS
> - Find remote cluster name that corresponds to remote ES output (match by host) or let users choose remote cluster on UI
> - Add callout that setting up a Remote Cluster for the Remote ES output is a prerequisite for this feature
> - Update installed integration assets with remote clusters in index patterns e.g. \`logs-\*,remote1:logs-\*\`
> - When opting out of CCS, update integration assets to remove the remote cluster from index patterns
> - When installing/upgrading an integration, include remote clusters in index patterns of assets
> - Potentially add a feature flag if the feature takes multiple prs
> \- \[\] Future enhancement: automate/unify the setup steps of remote clusters from remote ES output UI
>
> cc: @kpollich @cmacknz
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [January 21, 2025, 6:24pm UTC](https://discuss.elastic.co/t/regarding-cross-cluster-replication/372349/6 "2025-01-21T18:24:55Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.