big_data_service:best_practice
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
big_data_service:best_practice [2022/11/17 15:40] – [Considerations...] su | big_data_service:best_practice [2022/11/17 16:22] (current) – [What to do if you are approaching advised limits?] su | ||
---|---|---|---|
Line 15: | Line 15: | ||
==== Server Constraints ==== | ==== Server Constraints ==== | ||
- | The server hosting App Store Connect must have suitable for processing and storing data. Consider CPU, RAM, dirve size, drive type (SSD or hard disk). | + | The server hosting App Store Connect must have suitable for processing and storing data. Consider... |
+ | * CPU | ||
+ | * RAM | ||
+ | * Drive size | ||
+ | * Drive type (SSD or hard disk). | ||
Balance this against your requirements: | Balance this against your requirements: | ||
- | | + | * What are the data ingestion rates? |
- | - Are these consistant | + | * Is data collection constant |
- | - How manu users must you support? | + | |
==== Sharding ==== | ==== Sharding ==== | ||
+ | |||
+ | Data in elasticsearch are stored in shards and the size and number of shards will impact performance and stability. | ||
To obtain a list of all the shards on an elasticsearch node, open the following URL on your App Store Connect server. | To obtain a list of all the shards on an elasticsearch node, open the following URL on your App Store Connect server. | ||
Line 40: | Line 46: | ||
A default installation of App Store Connect allocates only 1GB of RAM to Elasticsearch. If the App Store Connect is importing Alarm Analysis data, it will create 2 shards per calendar month - thus reaching the recommended limit within 10 months. Even a node configured with the max 32GB RAM will reach its limit of 640 indices by 5 years if recording Alarm Analysis data for 5 assets. | A default installation of App Store Connect allocates only 1GB of RAM to Elasticsearch. If the App Store Connect is importing Alarm Analysis data, it will create 2 shards per calendar month - thus reaching the recommended limit within 10 months. Even a node configured with the max 32GB RAM will reach its limit of 640 indices by 5 years if recording Alarm Analysis data for 5 assets. | ||
+ | Exceeding these limits may lead to issues index corruption. For Alarm Analysis, this could manifest in the loss of monthly blocks of data. | ||
+ | |||
+ | ===== What to do if you are approaching advised limits? ===== | ||
+ | Most of the options below require specialist knowledge of elasticsearch. Consult with the Intelligent Plant team if unsure how to proceed. | ||
+ | |||
+ | **Data Source Configuration** \\ | ||
+ | Change data index settings that determine how data is stored. IP Historian exposes index type and sharding properties. \\ | ||
+ | NB. Modifying these settings on a live system is not advised. | ||
+ | |||
+ | **Scale Up** \\ | ||
+ | Increase server RAM and allocating more to the Big Data process. | ||
- | This may result in spurious index corruption issues. | + | **Scale Out** \\ |
+ | Introduce more elasticseach nodes on dedicated infrastructure. | ||
+ | **Data Archiving** \\ | ||
+ | Either remove old data, or migrate old data to another App Store Connect instance dediated to archiving. | ||
+ | **Data Consolidation** \\ | ||
+ | Re-index smaller data nodes together. For instance, consolidate Alarm Analysis monthly indices into single (one shard) indices. \\ | ||
+ | NB. The new index would need alias names of all the indices replaced in order to support application function. | ||
big_data_service/best_practice.1668699651.txt.gz · Last modified: 2022/11/17 15:40 by su