Hi all,
I'll need a help with resizing a storage for elasticsearch. We have deployed elasticserach with helm but we have an issue with resizing the storage. This are the resources that we deployed with helm:
> pod/sandbox-elasticsearch-test2-0 1/1 Running 0 63m
> pod/sandbox-elasticsearch-test2-1 1/1 Running 0 63m
>
> service/sandbox-elasticsearch-test2 ClusterIP 172.20.15.222 <none> 9200/TCP,9300/TCP 63m
> service/sandbox-elasticsearch-test2-headless ClusterIP None <none> 9200/TCP,9300/TCP 63m
> statefulset.apps/sandbox-elasticsearch-test2 2/2 63m
We tried to resize the storage by changing nodeGroup and masterService and we ended with new nodes but old one are deleted, only what is left is old storage disks :
sandbox-elasticsearch-test-sandbox-elasticsearch-test-0 Bound pvc-f45fe905-7f09-43aa-b4a5-5ef8124ad69e 120Gi RWO gp2-csi 18h
sandbox-elasticsearch-test-sandbox-elasticsearch-test-1 Bound pvc-5ed567f6-0aa4-4ebd-8162-42f7fa27ee0d 120Gi RWO gp2-csi 18h
sandbox-elasticsearch-test2-sandbox-elasticsearch-test2-0 Bound pvc-46a87003-3c90-453c-a3dc-de65877d60b7 130Gi RWO gp2-csi 64m
sandbox-elasticsearch-test2-sandbox-elasticsearch-test2-1 Bound pvc-334cfc32-a376-469a-ae9d-e7e0e2cf3c7a 130Gi RWO
I think data is still on old disks but how to migrate old data to new nodes ? After the attempt to resize the storage we ended up with a brand new cluster and old data are lost .
Hello,
You changed cluster name, so PVC name changed , thats why there are new PVs.
This is not really related to this Helm chart, but did you read https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/?
If you cant resize, you can consider to scale out, by creating more replicas, something like that:
kubectl delete sts XXX --cascade=false)I am not sure about "4", but this is the idea.
Hi @milijander88,
The good news is that PVC are never deleted by this chart so changing back nodeGroup and masterService to previous values should be enough to re-use the disks with datas.
As for the procedure to resize disk, changing volumeClaimTemplate.resources.requests.storage value would fail with Updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbidden error because this field is immutable at Kubernetes level. That's why even @ebuildy procedure would fail at step 1.
The recommended workaround for Elasticsearch chart is using a new chart release, with different storage size to replace the existing one.:
- Install a new deployment of the helm chart, with
nodeGroupset to a unique value, such asdata-1and the appropriate PVC claim size.- Ensure that these new ES nodes have joined the cluster.
- Trigger Elasticsearch to move all data off of the
datanodes. This can be achieved by using Cluster-level shard allocation filtering, using the IP's of the 3 originaldatanodes.- Once all data has been migrated off of the original
datanodes, then delete that helm deployment.
(source: https://github.com/elastic/helm-charts/issues/647#issuecomment-636778450)
This is related to #772, #893 and #647.
@jmlr I am now able to resize the pvc using a second release in parallel, wait for the data sync, then removing the original.
But, doing that, it also renames the elasticsearch service regarding $clusterName-$nodeGroup . And this make the service unavailable because it has been renamed.
Any idea how to do it properly ?
EDIT : actually I've resolve it by creating the multi chart release, at least one for the master and one for the data, as described here : https://github.com/elastic/helm-charts/tree/master/elasticsearch/examples/multi
Hi @milijander88,
The good news is that PVC are never deleted by this chart so changing backnodeGroupandmasterServiceto previous values should be enough to re-use the disks with datas.As for the procedure to resize disk, changing
volumeClaimTemplate.resources.requests.storagevalue would fail withUpdates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbiddenerror because this field is immutable at Kubernetes level. That's why even @ebuildy procedure would fail at step 1.The recommended workaround for Elasticsearch chart is using a new chart release, with different storage size to replace the existing one.:
- Install a new deployment of the helm chart, with
nodeGroupset to a unique value, such asdata-1and the appropriate PVC claim size.- Ensure that these new ES nodes have joined the cluster.
- Trigger Elasticsearch to move all data off of the
datanodes. This can be achieved by using Cluster-level shard allocation filtering, using the IP's of the 3 originaldatanodes.- Once all data has been migrated off of the original
datanodes, then delete that helm deployment.(source: #647 (comment))
This is related to #772, #893 and #647.
I forgot to mention: "remove StatefulSet before" (this will not remove associated pods), I used it many-times without data loss
@ebuildy Please can you once again share me the detailed steps to re-size the elastic search disk online.
Even as part of new project I have deployed elasticsearch with latest helm charts. Now I have to take it to production, but i'm afraid of re-sizing disk without downtime or data loss.
Your help would be much appriciated, so that i can test the upgradation before i move into production.
Most helpful comment
Hi @milijander88,
The good news is that PVC are never deleted by this chart so changing back
nodeGroupandmasterServiceto previous values should be enough to re-use the disks with datas.As for the procedure to resize disk, changing
volumeClaimTemplate.resources.requests.storagevalue would fail withUpdates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbiddenerror because this field is immutable at Kubernetes level. That's why even @ebuildy procedure would fail at step 1.The recommended workaround for Elasticsearch chart is using a new chart release, with different storage size to replace the existing one.:
(source: https://github.com/elastic/helm-charts/issues/647#issuecomment-636778450)
This is related to #772, #893 and #647.