-
Notifications
You must be signed in to change notification settings - Fork 25.6k
adding reference architectures section #115615
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
Conversation
Documentation preview: |
|
||
In the links provided above, elastic has performance tested hardware for each of the cloud providers to find the optimal hardware for each node type. We use ratios to represent the best mix of CPU, Ram, and Disk for each type. In some cases the CPU to RAM ratio is key, in others the disk to memory ratio and type of disk is critical. Significantly deviating from these ratios may look like a way to save on hardware costs, but may result in an Elasticsearch cluster that does not scale and perform well. | ||
|
||
The following table shows our specific recommendations for nodes in Hot / Frozen architecture. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The following table shows our specific recommendations for nodes in Hot / Frozen architecture. | |
The following table shows our specific recommendations for nodes in a Hot / Frozen architecture. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GitHub keeps threatening to lose my comments, so I'm submitting early. Most of my comments are global anyway, such as applying the "one sentence per line standard," using attributes for product names and internal URLs, capitalization, and shortening complex sentences.
All suggestions are consideration, and I trust your judgement on what to take and what to leave.
|
||
The Hot / Frozen high availability architecture is cost optimized for large time-series datasets. In this architecture, the hot tier is primarily used for indexing, searching, and continuity for automated processes. https://www.elastic.co/guide/en/elasticsearch/reference/current/searchable-snapshots.html[Searchable snapshots] are taken from hot into a repository, such as a cloud Object Store or an on-premesis shared filesystem, and then cached to any desired volume on the local disks of the Frozen tier. Data in the repository is indexed for fast retrieval and accessed on-demand from the Frozen nodes. Index and Snapshot lifecycle management are used to automate this process. | ||
|
||
This architecture is ideal for time-series use cases, such as Observability or Security, that do not require updating. All the necessary components of the Elastic Stack are included and this is not intended for sizing workloads, but rather as a basis to ensure your cluster is ready to handle any desired workload with resiliency. A very high level representation of data flow is included, and for more detail around ingest architecture see our https://www.elastic.co/guide/en/ingest/current/use-case-arch.html[ingest architectures] documentation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GLOBAL: {ingest-guide}/use-case-arch.html[ingest architectures] documentation.
Co-authored-by: David Kilfoyle <[email protected]>
Co-authored-by: Karen Metts <[email protected]> Co-authored-by: David Kilfoyle <[email protected]>
Looks great @georgewallace! I added some comments just for consistency with other docs, and I see @karenzone is picking up lots of stuff that I've missed. :-) |
Co-authored-by: David Kilfoyle <[email protected]>
Co-authored-by: David Kilfoyle <[email protected]> Co-authored-by: Karen Metts <[email protected]>
Co-authored-by: Karen Metts <[email protected]>
Co-authored-by: Karen Metts <[email protected]>
Creating reference architecture section