Skip to content

Conversation

georgewallace
Copy link
Contributor

Creating reference architecture section

@georgewallace georgewallace marked this pull request as draft October 25, 2024 03:06
Copy link
Contributor

Documentation preview:

@georgewallace georgewallace changed the title updates adding reference architectures section Oct 25, 2024

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.
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
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.

Copy link
Contributor

@karenzone karenzone left a 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.
Copy link
Contributor

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.

georgewallace and others added 2 commits December 4, 2024 07:43
Co-authored-by: Karen Metts <[email protected]>
Co-authored-by: David Kilfoyle <[email protected]>
@kilfoyle
Copy link
Contributor

kilfoyle commented Dec 4, 2024

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. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants