Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-order "Mirror requests to a second cluster" #1116

Merged
merged 2 commits into from
Feb 9, 2022

Conversation

jdbaldry
Copy link
Member

@jdbaldry jdbaldry commented Feb 8, 2022

Additionally replace references to Cortex with Grafana Mimir.

Relates to #1095.

Signed-off-by: Jack Baldry [email protected]

@jdbaldry jdbaldry added the type/docs Improvements or additions to documentation label Feb 8, 2022

<!-- prettier-ignore-start -->
[embedmd]:# (../configurations/requests-mirroring-envoy.yaml)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's still a lot of "cortex" naming in requests-mirroring-envoy.yaml (which is embedded in this markdown file). Can you edit it too, please?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in ecdfd58


## Mirroring with Envoy proxy

[Envoy proxy](https://www.envoyproxy.io/) can be used to mirror HTTP requests to a secondary upstream cluster. From a network path perspective, you should run Envoy in front of both clusters distributors, letting Envoy to proxy requests to the primary Cortex cluster and mirror them to a secondary cluster in background. The performances and availability of the secondary cluster have no impact on the requests to the primary one. The response to the client will always be the one from the primary one. In this sense, the requests from Envoy to the secondary cluster are "fire and forget".
[Envoy proxy](https://www.envoyproxy.io/) can be used to mirror HTTP requests to a secondary upstream cluster. From a network path perspective, you should run Envoy in front of both clusters distributors, letting Envoy to proxy requests to the primary Grafana Mimir cluster and mirror them to a secondary cluster in background. The performances and availability of the secondary cluster have no impact on the requests to the primary one. The response to the client will always be the one from the primary one. In this sense, the requests from Envoy to the secondary cluster are "fire and forget".
Copy link
Contributor

@replay replay Feb 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this, just seems easier to understand to me

Suggested change
[Envoy proxy](https://www.envoyproxy.io/) can be used to mirror HTTP requests to a secondary upstream cluster. From a network path perspective, you should run Envoy in front of both clusters distributors, letting Envoy to proxy requests to the primary Grafana Mimir cluster and mirror them to a secondary cluster in background. The performances and availability of the secondary cluster have no impact on the requests to the primary one. The response to the client will always be the one from the primary one. In this sense, the requests from Envoy to the secondary cluster are "fire and forget".
[Envoy proxy](https://www.envoyproxy.io/) can be used to mirror HTTP requests to a secondary upstream cluster. From a network path perspective, you should run Envoy in front of both clusters distributors, letting Envoy to proxy requests to the primary Grafana Mimir cluster and mirror them to a secondary cluster in background. The performances and availability of the secondary cluster have no impact on the requests to the primary one. The response to the client will always be the one from the primary one. In this sense, the requests from Envoy to the secondary cluster are "fire and forget".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change to clusters’.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in b4bbaee

jdbaldry and others added 2 commits February 9, 2022 17:40
Additionally replace references to Cortex with Grafana Mimir.

Relates to #1095.

Signed-off-by: Jack Baldry <[email protected]>
@jdbaldry jdbaldry force-pushed the jdb/2022-02-re-order-mirror-requests branch from 0073a22 to b4bbaee Compare February 9, 2022 17:43
@jdbaldry jdbaldry merged commit 161d711 into main Feb 9, 2022
@jdbaldry jdbaldry deleted the jdb/2022-02-re-order-mirror-requests branch February 9, 2022 17:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/docs Improvements or additions to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants