ਉਤਪਾਦਨ k3s ਕਲੱਸਟਰਾਂ ਲਈ ਲੋਂਗਹੋਰਨ ਸਟੋਰੇਜ: ਡਾਇਨਾਮਿਕ PVC ਵਿਸਥਾਰ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ, ਅਤੇ ਤਬਾਹੀ ਰਿਕਵਰੀ

ਸਟੋਰੇਜ Kubernetes ਵਿੱਚ ਸਭ ਤੋਂ ਮੁਸ਼ਕਿਲ ਸਮੱਸਿਆ ਹੈ। ਕੰਪਿਊਟ ਸਟੇਟਲੈਸ ਅਤੇ ਫੰਗੀਬਲ ਹੈ - ਇੱਕ ਪੌਡ ਨੂੰ ਮਾਰੋ, ਦੂਜੀ ਨੂੰ ਤਹਿ ਕਰੋ। ਨੈੱਟਵਰਕਿੰਗ ਵਿੱਚ ਪਰਿਪੱਕ CNI ਪਲੱਗਇਨ ਅਤੇ ਸਰਵਿਸ ਮੇਸ਼ ਹਨ। ਪਰ ਸਟੋਰੇਜ਼? ਸਟੋਰੇਜ ਉਹ ਹੈ ਜਿੱਥੇ ਰਾਜ ਰਹਿੰਦਾ ਹੈ, ਜਿੱਥੇ ਡਾਟਾ ਰੀਸਟਾਰਟ ਹੁੰਦਾ ਹੈ, ਜਿੱਥੇ ਇੱਕ ਸਿੰਗਲ ਗਲਤ ਸੰਰਚਨਾ ਦਾ ਮਤਲਬ ਸਥਾਈ ਡਾਟਾ ਨੁਕਸਾਨ ਹੋ ਸਕਦਾ ਹੈ। k3s ਕਲੱਸਟਰਾਂ ਲਈ ਜੋ ਉਤਪਾਦਨ ਵਰਕਲੋਡ ਚਲਾ ਰਹੇ ਹਨ — ਡਾਟਾਬੇਸ, ਸੰਦੇਸ਼ ਕਤਾਰ, ਐਪਲੀਕੇਸ਼ਨ ਸਥਿਤੀ — ਤੁਹਾਨੂੰ ਇੱਕ ਸਟੋਰੇਜ ਹੱਲ ਦੀ ਲੋੜ ਹੈ ਜੋ ਵੰਡਿਆ, ਲਚਕੀਲਾ, ਵਿਸਤਾਰਯੋਗ ਅਤੇ ਸੰਚਾਲਿਤ ਹੋਵੇ। Longhorn ਉਹ ਹੱਲ ਹੈ.

Longhorn Kubernetes ਲਈ ਇੱਕ ਹਲਕਾ, ਭਰੋਸੇਮੰਦ, ਅਤੇ ਵਰਤੋਂ ਵਿੱਚ ਆਸਾਨ ਵੰਡਿਆ ਹੋਇਆ ਬਲਾਕ ਸਟੋਰੇਜ ਸਿਸਟਮ ਹੈ। ਮੂਲ ਰੂਪ ਵਿੱਚ ਰੈਂਚਰ ਲੈਬਜ਼ (ਹੁਣ SUSE ਦਾ ਹਿੱਸਾ) ਦੁਆਰਾ ਵਿਕਸਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਇਹ ਇੱਕ CNCF ਇਨਕਿਊਬੇਟਿੰਗ ਪ੍ਰੋਜੈਕਟ ਹੈ- ਕਲੱਸਟਰਾਂ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ ਜਿੱਥੇ ਸਾਦਗੀ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ ਪਰ ਉਤਪਾਦਨ ਭਰੋਸੇਯੋਗਤਾ ਗੈਰ-ਗੱਲਬਾਤਯੋਗ ਹੈ। Ceph ਦੇ ਉਲਟ, ਜੋ ਸਮਰਪਿਤ ਸਟੋਰੇਜ ਨੋਡਸ ਅਤੇ ਡੂੰਘੀ ਮੁਹਾਰਤ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਜਾਂ ਲੋਕਲ-ਪਾਥ ਪ੍ਰੋਵੀਜ਼ਨਰ, ਜੋ ਜ਼ੀਰੋ ਰਿਡੰਡੈਂਸੀ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ, ਲੋਂਗਹੋਰਨ k3s ਕਲੱਸਟਰਾਂ ਲਈ ਲੋੜੀਂਦੇ ਸਹੀ ਸੰਤੁਲਨ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ: ਨੋਡਾਂ ਵਿੱਚ ਵੰਡੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ, ਗਤੀਸ਼ੀਲ ਵੌਲਯੂਮ ਵਿਸਤਾਰ, ਕਲਾਉਡ ਆਬਜੈਕਟ ਸਟੋਰੇਜ਼ ਲਈ ਏਕੀਕ੍ਰਿਤ ਬੈਕਅੱਪ, ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਕਲੀਨ UI ਦਾ ਪ੍ਰਬੰਧਨ - ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਕਲੀਨ UI ਦਾ ਪ੍ਰਬੰਧਨ। Kubernetes-ਦੇਸੀ CRDs।

ਇਹ ਗਾਈਡ ਉਹ ਸਭ ਕੁਝ ਕਵਰ ਕਰਦੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਉਤਪਾਦਨ ਲਈ k3s 'ਤੇ ਲੋਂਗਹੋਰਨ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ: ਆਰਕੀਟੈਕਚਰ ਇੰਟਰਨਲ, ਇੰਸਟਾਲੇਸ਼ਨ ਵਿਧੀਆਂ, ਸਟੋਰੇਜ ਕਲਾਸ ਕੌਂਫਿਗਰੇਸ਼ਨ, ਡਾਇਨਾਮਿਕ PVC ਵਿਸਤਾਰ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਰਣਨੀਤੀਆਂ, ਬੈਕਅਪ ਅਤੇ ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ, ਵੌਲਯੂਮ ਇਨਕ੍ਰਿਪਸ਼ਨ, ਪ੍ਰਦਰਸ਼ਨ ਟਿਊਨਿੰਗ ਅਤੇ ਡਾਟਾਬੇਸ ਦੀ ਨਿਗਰਾਨੀ, ਸਮੱਸਿਆ ਦੀ ਨਿਗਰਾਨੀ। ਹਰੇਕ ਸਿਫ਼ਾਰਿਸ਼ ਉਤਪਾਦਨ-ਟੈਸਟ ਕੀਤੀ ਸੰਰਚਨਾ ਦੇ ਨਾਲ ਆਉਂਦੀ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਆਪਣੇ ਵਾਤਾਵਰਣ ਦੇ ਅਨੁਕੂਲ ਬਣਾ ਸਕਦੇ ਹੋ।

ਲੋਂਗਹੋਰਨ ਆਰਕੀਟੈਕਚਰ

ਲੌਂਗਹੋਰਨ ਦੇ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸਮਝਣਾ ਪ੍ਰਤੀਕ੍ਰਿਤੀ, ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਅਸਫਲਤਾ ਨੂੰ ਸੰਭਾਲਣ ਬਾਰੇ ਸੂਚਿਤ ਫੈਸਲੇ ਲੈਣ ਲਈ ਜ਼ਰੂਰੀ ਹੈ। Longhorn ਤਿੰਨ ਮੁੱਖ ਭਾਗਾਂ ਤੋਂ ਬਣਿਆ ਹੈ ਜੋ ਤੁਹਾਡੇ Kubernetes ਨੋਡਾਂ ਨਾਲ ਜੁੜੀਆਂ ਸਥਾਨਕ ਡਿਸਕਾਂ ਦੇ ਸਿਖਰ 'ਤੇ ਵੰਡਿਆ ਬਲਾਕ ਸਟੋਰੇਜ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਇਕੱਠੇ ਕੰਮ ਕਰਦੇ ਹਨ।

ਲੌਂਗਹੋਰਨ ਮੈਨੇਜਰਕਲੱਸਟਰ ਵਿੱਚ ਹਰੇਕ ਨੋਡ 'ਤੇ ਇੱਕ ਡੈਮਨਸੈੱਟ ਵਜੋਂ ਚੱਲਦਾ ਹੈ। ਇਹ ਲੋਂਗਹੋਰਨ ਦਾ ਕੰਟਰੋਲ ਪਲੇਨ ਹੈ — ਇਹ API ਕਾਲਾਂ ਨੂੰ ਹੈਂਡਲ ਕਰਦਾ ਹੈ, ਵਾਲੀਅਮ ਬਣਾਉਣ ਦਾ ਆਰਕੈਸਟ੍ਰੇਟ ਕਰਦਾ ਹੈ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ, ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਬੈਕਅੱਪ ਦਾ ਤਾਲਮੇਲ ਕਰਦਾ ਹੈ, ਅਤੇ PersistentVolume ਅਤੇ PersistentVolumeClaim ਜੀਵਨ ਚੱਕਰ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ Kubernetes API ਸਰਵਰ ਨਾਲ ਸੰਚਾਰ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ PVC ਬਣਾਉਂਦੇ ਹੋ ਜੋ ਇੱਕ Longhorn StorageClass ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ, ਤਾਂ Longhorn Manager CSI ਡਰਾਈਵਰ ਦੁਆਰਾ ਬੇਨਤੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਵਾਲੀਅਮ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਪਲਬਧ ਨੋਡਾਂ ਵਿੱਚ ਇਸਦੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨੂੰ ਤਹਿ ਕਰਦਾ ਹੈ।

ਲੋਂਗਹੋਰਨ ਇੰਜਣਇੱਕ ਪ੍ਰਤੀ-ਵਾਲਿਊਮ ਸਟੋਰੇਜ ਕੰਟਰੋਲਰ ਹੈ ਜੋ ਇੱਕ ਲੀਨਕਸ ਯੂਜ਼ਰਸਪੇਸ ਪ੍ਰਕਿਰਿਆ (ਰੈਂਚਰ ਲੋਂਗਹੋਰਨ ਇੰਜਣ ਦੇ ਫੋਰਕ 'ਤੇ ਆਧਾਰਿਤ) ਵਜੋਂ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ। ਹਰੇਕ ਵਾਲੀਅਮ ਨੋਡ 'ਤੇ ਚੱਲ ਰਹੀ ਆਪਣੀ ਸਮਰਪਿਤ ਇੰਜਣ ਪ੍ਰਕਿਰਿਆ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਵਾਲੀਅਮ ਜੁੜਿਆ ਹੁੰਦਾ ਹੈ। ਇੰਜਣ ਉਸ ਵਾਲੀਅਮ ਲਈ ਸਾਰੇ ਰੀਡ ਅਤੇ ਰਾਈਟ I/O ਨੂੰ ਹੈਂਡਲ ਕਰਦਾ ਹੈ, ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਰਾਈਟ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਾਰੀਆਂ ਸੰਰਚਨਾ ਕੀਤੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨੂੰ ਸਮਕਾਲੀ ਤੌਰ 'ਤੇ ਕਾਪੀ ਕਰਨਾ। ਇਸ ਪ੍ਰਤੀ-ਵਾਲੀਅਮ ਆਰਕੀਟੈਕਚਰ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਵਾਲੀਅਮ ਦੇ ਇੰਜਣ ਵਿੱਚ ਇੱਕ ਕਰੈਸ਼ ਜਾਂ ਹੈਂਗ ਕਿਸੇ ਹੋਰ ਵਾਲੀਅਮ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦਾ - ਉਤਪਾਦਨ ਲਈ ਇੱਕ ਨਾਜ਼ੁਕ ਅਲੱਗ-ਥਲੱਗ ਵਿਸ਼ੇਸ਼ਤਾ।

ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂਅਸਲ ਡਾਟਾ ਸਟੋਰੇਜ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹਨ। ਹਰੇਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੋਡ ਦੀ ਸਥਾਨਕ ਡਿਸਕ 'ਤੇ ਵਾਲੀਅਮ ਡੇਟਾ ਦੀ ਇੱਕ ਪੂਰੀ ਕਾਪੀ ਸਟੋਰ ਕਰਦੀ ਹੈ ਜਿੱਥੇ ਇਹ ਚੱਲਦਾ ਹੈ। ਮੂਲ ਰੂਪ ਵਿੱਚ, ਲੋਂਗਹੋਰਨ ਹਰੇਕ ਵਾਲੀਅਮ ਲਈ ਤਿੰਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਬਣਾਉਂਦਾ ਹੈ, ਵੱਖ-ਵੱਖ ਨੋਡਾਂ (ਅਤੇ ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਜ਼ੋਨ) ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ। ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਸਨੈਪਸ਼ਾਟ ਲਈ ਕਾਪੀ-ਆਨ-ਰਾਈਟ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਸਨੈਪਸ਼ਾਟ ਬਣਾਉਣਾ ਵੌਲਯੂਮ ਆਕਾਰ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਤੁਰੰਤ ਬਣ ਜਾਂਦਾ ਹੈ।

ਇਹ ਆਰਕੀਟੈਕਚਰ ਉਤਪਾਦਨ ਵਰਤੋਂ ਲਈ ਕਈ ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।ਫਾਲਟ ਸਹਿਣਸ਼ੀਲਤਾ:ਤਿੰਨ ਨੋਡਾਂ ਵਿੱਚ ਤਿੰਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੇ ਨਾਲ, ਵਾਲੀਅਮ ਦੋ ਸਮਕਾਲੀ ਨੋਡ ਅਸਫਲਤਾਵਾਂ ਤੋਂ ਬਚਦਾ ਹੈ।ਆਈਸੋਲੇਸ਼ਨ:ਹਰੇਕ ਵਾਲੀਅਮ ਦੀ ਆਪਣੀ ਇੰਜਣ ਪ੍ਰਕਿਰਿਆ ਹੁੰਦੀ ਹੈ, ਇਸਲਈ ਇੱਕ ਵਾਲੀਅਮ ਵਿੱਚ ਇੱਕ ਬੱਗ ਜਾਂ ਹੈਂਗ ਕੈਸਕੇਡ ਨਹੀਂ ਹੋ ਸਕਦਾ।ਸਾਦਗੀ:ਕੋਈ ਸਮਰਪਿਤ ਸਟੋਰੇਜ ਨੋਡ ਨਹੀਂ, ਕੋਈ ਵੱਖਰਾ Ceph ਜਾਂ GlusterFS ਕਲੱਸਟਰ ਨਹੀਂ — ਲੋਂਗਹੋਰਨ ਉਹਨਾਂ ਦੀ ਸਥਾਨਕ ਡਿਸਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ ਪੌਡਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਉਸੇ ਵਰਕਰ ਨੋਡਾਂ 'ਤੇ ਚੱਲਦਾ ਹੈ।Kubernetes-ਨੇਟਿਵ:ਸਭ ਕੁਝ CRDs, kubectl, ਅਤੇ Kubernetes CSI ਇੰਟਰਫੇਸ ਦੁਆਰਾ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

k3s

Longhorn ਨੂੰ k3s 'ਤੇ ਤਿੰਨ ਤਰੀਕਿਆਂ ਰਾਹੀਂ ਸਥਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: Helm ਚਾਰਟ (ਉਤਪਾਦਨ ਲਈ ਸਿਫ਼ਾਰਸ਼ ਕੀਤਾ ਗਿਆ), ਰੈਂਚਰ ਐਪ ਮਾਰਕਿਟਪਲੇਸ (ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਰੈਂਚਰ ਤੁਹਾਡੇ ਕਲੱਸਟਰ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰ ਰਿਹਾ ਹੈ), ਜਾਂ ਸਿੱਧਾ kubectl ਲਾਗੂ ਕਰੋ। ਇੰਸਟਾਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਨੋਡ ਪੂਰਵ-ਲੋੜਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਨ।

ਪੂਰਵ-ਲੋੜਾਂ

# Verify prerequisites on each node
# Required: open-iscsi (for iSCSI support)
sudo apt-get install -y open-iscsi
sudo systemctl enable iscsid
sudo systemctl start iscsid

# Required: NFSv4 client (for backup/restore to NFS targets)
sudo apt-get install -y nfs-common

# Recommended: check all prerequisites with Longhorn's environment check script
curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/v1.7.2/scripts/environment_check.sh | bash

# Verify kernel modules
lsmod | grep -E "iscsi_tcp|dm_crypt|nfs"

# On k3s specifically, local-path-provisioner is the default.
# We will make Longhorn the default StorageClass after installation.

Helm ਦੁਆਰਾ ਸਥਾਪਨਾ (ਸਿਫਾਰਸ਼ੀ)

# Add the Longhorn Helm repository
helm repo add longhorn https://charts.longhorn.io
helm repo update

# Create the namespace
kubectl create namespace longhorn-system

# Install with production values
helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --version 1.7.2 \
  --values longhorn-values.yaml

ਇੱਥੇ ਟਿਊਨ ਕੀਤੇ ਡਿਫੌਲਟਸ ਦੇ ਨਾਲ ਇੱਕ ਉਤਪਾਦਨ-ਗ੍ਰੇਡvalues.yamlਹੈ:

# longhorn-values.yaml — Production configuration
persistence:
  defaultClass: true
  defaultFsType: ext4
  defaultClassReplicaCount: 3
  defaultDataLocality: best-effort
  reclaimPolicy: Retain

defaultSettings:
  backupTarget: s3://longhorn-backups@eu-west-1/
  backupTargetCredentialSecret: longhorn-backup-s3-secret
  createDefaultDiskLabeledNodes: true
  defaultDataPath: /var/lib/longhorn/
  defaultReplicaCount: 3
  defaultDataLocality: best-effort
  replicaSoftAntiAffinity: false
  replicaAutoBalance: best-effort
  storageOverProvisioningPercentage: 150
  storageMinimalAvailablePercentage: 15
  guaranteedInstanceManagerCPU: 12
  upgradeChecker: false
  autoSalvage: true
  autoDeletePodWhenVolumeDetachedUnexpectedly: true
  disableSchedulingOnCordonedNode: true
  replicaZoneSoftAntiAffinity: true
  volumeAttachmentRecoveryPolicy: wait
  snapshotDataIntegrity: fast-check
  snapshotDataIntegrityCronjob: "0 7 * * *"
  concurrentAutomaticEngineUpgradePerNodeLimit: 1

longhornManager:
  priorityClass: system-cluster-critical
  tolerations:
    - key: "node-role.kubernetes.io/storage"
      operator: "Exists"
      effect: "NoSchedule"

longhornDriver:
  priorityClass: system-cluster-critical
  tolerations:
    - key: "node-role.kubernetes.io/storage"
      operator: "Exists"
      effect: "NoSchedule"

longhornUI:
  replicas: 2

ingress:
  enabled: true
  ingressClassName: nginx
  host: longhorn.internal.example.com
  tls: true
  tlsSecret: longhorn-tls
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: longhorn-basic-auth
    nginx.ingress.kubernetes.io/auth-realm: "Longhorn UI"

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

ਸਥਾਪਨਾ

ਜੇਕਰ ਰੈਂਚਰ ਤੁਹਾਡੇ k3s ਕਲੱਸਟਰ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ, ਤਾਂਐਪਸ & ਰੈਂਚਰ UI ਵਿੱਚ ਮਾਰਕੀਟਪਲੇਸ → ਚਾਰਟਸ → Longhorn। ਆਪਣਾ ਨਿਸ਼ਾਨਾ ਨੇਮਸਪੇਸ (longhorn-system) ਚੁਣੋ, ਫਾਰਮ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਮੁੱਲਾਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰੋ, ਅਤੇ ਇੰਸਟਾਲ 'ਤੇ ਕਲਿੱਕ ਕਰੋ। ਰੈਂਚਰ Helm ਲਾਈਫਸਾਈਕਲ ਪ੍ਰਬੰਧਨ ਅਤੇ ਅਪਗ੍ਰੇਡ ਟਰੈਕਿੰਗ ਨੂੰ ਆਪਣੇ ਆਪ ਸੰਭਾਲਦਾ ਹੈ।

ਸਥਾਪਨਾ

# Direct manifest installation
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.7.2/deploy/longhorn.yaml

# Verify all pods are running
kubectl -n longhorn-system get pods -w

ਪੋਸਟ-ਇੰਸਟਾਲੇਸ਼ਨ: ਲੋਂਗਹੋਰਨ ਨੂੰ ਡਿਫੌਲਟ ਸਟੋਰੇਜ ਕਲਾਸ

# Remove default annotation from k3s local-path
kubectl patch storageclass local-path -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

# Verify Longhorn is now default
kubectl get storageclass
# NAME                 PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
# longhorn (default)   driver.longhorn.io   Retain          Immediate           true                   5m
# local-path           rancher.io/local-path Delete         WaitForFirstConsumer false                 30d

ਸਟੋਰੇਜ ਕਲਾਸ ਕੌਂਫਿਗਰੇਸ਼ਨ

ਡਿਫੌਲਟ Longhorn StorageClass ਵਿਕਾਸ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਉਤਪਾਦਨ ਵਰਕਲੋਡ ਨੂੰ ਵੱਖ-ਵੱਖ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਲਈ ਖਾਸ ਸੰਰਚਨਾਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ — ਡਾਟਾਬੇਸ ਨੂੰ ਉੱਚ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਤੇ ਖਾਸ ਡਾਟਾ ਸਥਾਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਸਥਾਈ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਤੇਜ਼ ਸਿੰਗਲ-ਰਿਪਲੀਕਾ ਵਾਲੀਅਮ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਸ਼ੇਅਰਡ ਵਾਲੀਅਮਾਂ ਨੂੰ RWX ਸਮਰਥਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

# StorageClass for database workloads — maximum durability
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-db
  annotations:
    storageclass.kubernetes.io/is-default-class: "false"
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Retain
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  fromBackup: ""
  fsType: ext4
  dataLocality: best-effort
  recurringJobSelector: '[{"name":"db-snapshot","isGroup":true},{"name":"db-backup","isGroup":true}]'
---
# StorageClass for general workloads — balanced
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-standard
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "2"
  staleReplicaTimeout: "2880"
  fsType: ext4
  dataLocality: best-effort
---
# StorageClass for temporary/cache workloads — performance
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-fast
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "1"
  staleReplicaTimeout: "2880"
  fsType: ext4
  dataLocality: strict-local
---
# StorageClass for RWX (ReadWriteMany) shared volumes
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-rwx
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Retain
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "3"
  nfsOptions: "vers=4.1,hard,timeo=50,retrans=3"
  staleReplicaTimeout: "2880"
  fsType: ext4

ਡਾਇਨਾਮਿਕ PVC ਵਿਸਤਾਰ

ਲੋਂਗਹੋਰਨ ਦੀਆਂ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਉਤਪਾਦਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਗਤੀਸ਼ੀਲ PVC ਵਿਸਤਾਰ ਹੈ — ਬਿਨਾਂ ਡਾਊਨਟਾਈਮ, ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਦੇ, ਅਤੇ ਇੱਕ ਸਿੰਗਲ ਕਿਊਬੈਕਟਲ ਕਮਾਂਡ ਜਾਂ ਮੈਨੀਫੈਸਟ ਤਬਦੀਲੀ ਤੋਂ ਪਰੇ ਦਸਤੀ ਦਖਲ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਨਿਰੰਤਰ ਵਾਲੀਅਮ ਦੇ ਆਕਾਰ ਨੂੰ ਵਧਾਉਣ ਦੀ ਸਮਰੱਥਾ। ਇਹ ਉਹਨਾਂ ਡੇਟਾਬੇਸ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਿੱਥੇ ਡੇਟਾ ਵਾਧਾ ਅਨੁਮਾਨਿਤ ਨਹੀਂ ਹੈ ਅਤੇ ਡਿਸਕ ਸਪੇਸ ਦੇ ਖਤਮ ਹੋਣ ਦਾ ਮਤਲਬ ਹੈ ਆਊਟੇਜ।

ਲੌਂਗਹੋਰਨਔਨਲਾਈਨ ਵਿਸਤਾਰ(ਵੋਲਿਊਮ ਜੁੜਿਆ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਇਹ ਵਧਦਾ ਹੈ) ਅਤੇਔਫਲਾਈਨ ਵਿਸਤਾਰ(ਵੋਲਿਊਮ ਪਹਿਲਾਂ ਵੱਖ ਕੀਤਾ ਜਾਂਦਾ ਹੈ) ਦੋਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਔਨਲਾਈਨ ਵਿਸਤਾਰ ਉਤਪਾਦਨ ਲਈ ਡਿਫੌਲਟ ਅਤੇ ਸਿਫਾਰਸ਼ੀ ਪਹੁੰਚ ਹੈ ਕਿਉਂਕਿ ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਡਾਊਨਟਾਈਮ ਤੋਂ ਬਚਦਾ ਹੈ।

ਸਟੋਰੇਜ ਕਲਾਸ

ਡਾਇਨਾਮਿਕ PVC ਵਿਸਥਾਰ ਲਈ ਮੁੱਖ ਲੋੜ ਇਹ ਹੈ ਕਿ ਸਟੋਰੇਜ ਕਲਾਸ ਵਿੱਚallowVolumeExpansion: trueਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਲੋਂਗਹੋਰਨ ਡਿਫੌਲਟ ਸਟੋਰੇਜ ਕਲਾਸ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਇਹ ਸ਼ਾਮਲ ਹੈ, ਪਰ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਕਸਟਮ ਸਟੋਰੇਜ ਕਲਾਸਾਂ ਹਨ, ਤਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਖੇਤਰ ਸੈੱਟ ਹੈ।

# Verify your StorageClass supports expansion
kubectl get storageclass longhorn -o yaml | grep allowVolumeExpansion
# allowVolumeExpansion: true

# If not set, patch it
kubectl patch storageclass longhorn -p '{"allowVolumeExpansion": true}'

ਕਦਮ-ਦਰ-ਕਦਮ: ਇੱਕ PVC ਨੂੰ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ

# 1. Check current PVC size
kubectl get pvc pg-data-postgresql-0 -n database
# NAME                    STATUS   VOLUME       CAPACITY   ACCESS MODES   STORAGECLASS   AGE
# pg-data-postgresql-0    Bound    pvc-abc123   50Gi       RWO            longhorn-db    30d

# 2. Check current usage inside the pod
kubectl exec -n database postgresql-0 -- df -h /var/lib/postgresql/data
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/longhorn   49G   42G  7.0G  86% /var/lib/postgresql/data

# 3. Expand the PVC (online — no downtime)
kubectl patch pvc pg-data-postgresql-0 -n database --type merge -p '{
  "spec": {
    "resources": {
      "requests": {
        "storage": "100Gi"
      }
    }
  }
}'

# 4. Watch the expansion progress
kubectl get pvc pg-data-postgresql-0 -n database -w
# Wait for CAPACITY to update from 50Gi to 100Gi

# 5. Verify the filesystem expanded inside the pod
kubectl exec -n database postgresql-0 -- df -h /var/lib/postgresql/data
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/longhorn   99G   42G   57G  43% /var/lib/postgresql/data

# 6. Verify via Longhorn volume status
kubectl -n longhorn-system get volumes.longhorn.io -o wide

ਅਲਰਟ

ਉਤਪਾਦਨ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਉਦੋਂ ਤੱਕ ਇੰਤਜ਼ਾਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਜਦੋਂ ਤੱਕ ਇੱਕ ਡਿਸਕ 86% ਭਰੀ ਨਹੀਂ ਜਾਂਦੀ ਤਾਂ ਕਿ ਇਸਨੂੰ ਹੱਥੀਂ ਫੈਲਾਇਆ ਜਾ ਸਕੇ। ਆਪਣੇ ਆਪ ਵਿਸਥਾਰ ਨੂੰ ਟਰਿੱਗਰ ਕਰਨ ਲਈ Prometheus ਚੇਤਾਵਨੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜਾਂ ਸਮਰੱਥਾ ਦੇ ਨਾਜ਼ੁਕ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਆਨ-ਕਾਲ ਇੰਜੀਨੀਅਰ ਨੂੰ ਸੁਚੇਤ ਕਰੋ।

# PrometheusRule for PVC capacity alerts
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: pvc-capacity-alerts
  namespace: monitoring
spec:
  groups:
    - name: pvc-capacity
      rules:
        - alert: PVCCapacityWarning
          expr: |
            (kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes) > 0.80
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "PVC {{ $labels.persistentvolumeclaim }} at {{ $value | humanizePercentage }} capacity"
            runbook: "Expand the PVC using: kubectl patch pvc {{ $labels.persistentvolumeclaim }} -n {{ $labels.namespace }} --type merge -p '{\"spec\":{\"resources\":{\"requests\":{\"storage\":\"NEW_SIZE\"}}}}'"
        - alert: PVCCapacityCritical
          expr: |
            (kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes) > 0.90
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "CRITICAL: PVC {{ $labels.persistentvolumeclaim }} at {{ $value | humanizePercentage }}"
            description: "Immediate expansion required to prevent application failure"

ਵਾਲੀਅਮ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਤੇ ਡਾਟਾ ਸਥਾਨ

Longhorn ਹਾਰਡਵੇਅਰ ਫੇਲ੍ਹ ਹੋਣ ਤੋਂ ਬਚਾਉਣ ਲਈ ਕਈ ਨੋਡਾਂ ਵਿੱਚ ਵਾਲੀਅਮ ਡੇਟਾ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ। ਰਿਪਲੀਕੇਸ਼ਨ ਫੈਕਟਰ ਅਤੇ ਡੇਟਾ ਲੋਕਲਿਟੀ ਸੈਟਿੰਗਜ਼ ਟਿਕਾਊਤਾ, ਪ੍ਰਦਰਸ਼ਨ, ਅਤੇ ਸਟੋਰੇਜ ਕੁਸ਼ਲਤਾ ਦੇ ਵਿਚਕਾਰ ਵਪਾਰ-ਬੰਦ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੀਆਂ ਹਨ।

ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਕਾਰਕਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਡੇਟਾ ਦੀਆਂ ਕਿੰਨੀਆਂ ਕਾਪੀਆਂ ਮੌਜੂਦ ਹਨ। ਡਿਫੌਲਟ 3 ਹੈ, ਮਤਲਬ ਕਿ ਹਰੇਕ ਲਿਖਤ ਨੂੰ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਨੋਡਾਂ 'ਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਉਤਪਾਦਨ ਡੇਟਾਬੇਸ ਲਈ, 3 ਘੱਟੋ-ਘੱਟ ਸਿਫ਼ਾਰਸ਼ ਕੀਤਾ ਮੁੱਲ ਹੈ। ਤੁਸੀਂ ਸਟੋਰੇਜ ਨੂੰ ਬਚਾਉਣ ਲਈ ਘੱਟ ਨਾਜ਼ੁਕ ਵਰਕਲੋਡਾਂ ਲਈ ਇਸਨੂੰ 2 'ਤੇ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਇਸ ਨੂੰ ਅਸਥਾਈ/ਕੈਸ਼ ਵਾਲੀਅਮ ਲਈ 1 'ਤੇ ਛੱਡ ਸਕਦੇ ਹੋ ਜਿੱਥੇ ਡਾਟਾ ਨੁਕਸਾਨ ਸਵੀਕਾਰਯੋਗ ਹੈ।

ਡਾਟਾ ਲੋਕਲਿਟੀਇਹ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਲੋਂਗਹੋਰਨ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਉਸੇ ਨੋਡ 'ਤੇ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਜੋ ਪੌਡ ਦੀ ਮਾਤਰਾ ਨੂੰ ਖਪਤ ਕਰਦਾ ਹੈ। ਇੱਥੇ ਤਿੰਨ ਮੋਡ ਹਨ:

• ਅਸਮਰਥਿਤ— ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਉਪਲਬਧ ਸਪੇਸ ਅਤੇ ਐਂਟੀ-ਐਫੀਨਿਟੀ ਦੇ ਆਧਾਰ 'ਤੇ ਨਿਯਤ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ। ਪੌਡ ਇੱਕ ਰਿਮੋਟ ਨੋਡ 'ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਤੋਂ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਹਰ I/O ਓਪਰੇਸ਼ਨ ਲਈ ਨੈੱਟਵਰਕ ਲੇਟੈਂਸੀ ਜੋੜਦਾ ਹੈ।
• ਸਭ ਤੋਂ ਵਧੀਆ ਕੋਸ਼ਿਸ਼— ਲੋਂਗਹੋਰਨ ਖਪਤ ਕਰਨ ਵਾਲੇ ਪੌਡ ਦੇ ਸਮਾਨ ਨੋਡ 'ਤੇ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਲੋਕਲ ਨੋਡ ਸਪੇਸ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ ਜਾਂ ਪੌਡ ਮਾਈਗ੍ਰੇਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਵਾਲੀਅਮ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਇਸਦੀ ਲੇਟੈਂਸੀ ਥੋੜ੍ਹੀ ਜ਼ਿਆਦਾ ਹੋ ਸਕਦੀ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਵਰਕਲੋਡਾਂ ਲਈ ਇਹ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ ਸੈਟਿੰਗ ਹੈ।
• ਸਖਤ-ਸਥਾਨਕ— ਵਾਲੀਅਮ ਸਿਰਫ ਇੱਕ ਨੋਡ 'ਤੇ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜਿਸਦੀ ਸਥਾਨਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਹੈ। ਜੇਕਰ ਪੌਡ ਨੂੰ ਸਥਾਨਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਤੋਂ ਬਿਨਾਂ ਨੋਡ ਲਈ ਤਹਿ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਵਾਲੀਅਮ ਅਟੈਚਮੈਂਟ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਸਦੀ ਵਰਤੋਂ ਸਿਰਫ਼ ਲੇਟੈਂਸੀ-ਸੰਵੇਦਨਸ਼ੀਲ ਸਿੰਗਲ-ਰਿਪਲੀਕਾ ਵਰਕਲੋਡਾਂ ਲਈ ਕਰੋ ਜਿੱਥੇ ਤੁਸੀਂ ਟਿਕਾਊਤਾ ਵਪਾਰ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ।

# Change replication factor on an existing volume
kubectl -n longhorn-system patch volumes.longhorn.io pvc-abc123 \
  --type merge -p '{"spec":{"numberOfReplicas":3}}'

# Set data locality on existing volume
kubectl -n longhorn-system patch volumes.longhorn.io pvc-abc123 \
  --type merge -p '{"spec":{"dataLocality":"best-effort"}}'

# Replica auto-balancing (spreads replicas evenly across nodes)
# Set via Longhorn settings
kubectl -n longhorn-system edit settings.longhorn.io replica-auto-balance
# Set value to: best-effort

ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਬੈਕਅੱਪ

Longhorn ਦੋ ਵੱਖਰੀਆਂ ਡਾਟਾ ਸੁਰੱਖਿਆ ਵਿਧੀਆਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ:ਸਨੈਪਸ਼ਾਟ(ਸਥਾਨਕ, ਤਤਕਾਲ, ਤੇਜ਼ ਰੋਲਬੈਕ ਲਈ) ਅਤੇਬੈਕਅੱਪ(ਰਿਮੋਟ, ਆਬਜੈਕਟ ਸਟੋਰੇਜ, ਆਫ਼ਤ ਰਿਕਵਰੀ ਲਈ)। ਹਰੇਕ ਨੂੰ ਕਦੋਂ ਵਰਤਣਾ ਹੈ ਇਹ ਸਮਝਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ਸਨੈਪਸ਼ਾਟ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਉਸੇ ਡਿਸਕ 'ਤੇ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜਿਵੇਂ ਕਿ ਵਾਲੀਅਮ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ। ਉਹਨਾਂ ਨੂੰ ਕਾਪੀ-ਆਨ-ਰਾਈਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤੁਰੰਤ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ — ਸਨੈਪਸ਼ਾਟ ਸਮੇਂ 'ਤੇ ਕੋਈ ਡਾਟਾ ਕਾਪੀ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਸਨੈਪਸ਼ਾਟ ਤੋਂ ਬਾਅਦ ਸਿਰਫ਼ ਨਵੀਆਂ ਲਿਖਤਾਂ ਵਾਧੂ ਥਾਂ ਨਿਰਧਾਰਤ ਕਰਦੀਆਂ ਹਨ। ਸਨੈਪਸ਼ਾਟ ਇੱਕ ਜੋਖਮ ਭਰੇ ਮਾਈਗ੍ਰੇਸ਼ਨ ਜਾਂ ਤੈਨਾਤੀ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਰੋਲਬੈਕ ਲਈ ਸ਼ਾਨਦਾਰ ਹਨ, ਪਰ ਉਹ ਨੋਡ ਜਾਂ ਡਿਸਕ ਅਸਫਲਤਾ ਤੋਂ ਸੁਰੱਖਿਆ ਨਹੀਂ ਕਰਦੇ ਕਿਉਂਕਿ ਉਹ ਵਾਲੀਅਮ ਦੇ ਸਮਾਨ ਸਟੋਰੇਜ 'ਤੇ ਰਹਿੰਦੇ ਹਨ।

ਬੈਕਅੱਪ ਵਾਲੀਅਮ ਡੇਟਾ ਨੂੰ ਇੱਕ ਬਾਹਰੀ ਬੈਕਅੱਪ ਟੀਚੇ — S3, GCS, Azure ਬਲੌਬ, ਜਾਂ ਕਿਸੇ ਵੀ S3-ਅਨੁਕੂਲ ਸਟੋਰ (MinIO, Wasabi) ਵਿੱਚ ਕਾਪੀ ਕਰਦੇ ਹਨ। ਬੈਕਅਪ ਬਲਾਕ ਪੱਧਰ 'ਤੇ ਵਧਦੇ ਜਾਂਦੇ ਹਨ: ਸਿਰਫ ਉਹ ਬਲਾਕ ਟ੍ਰਾਂਸਫਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜੋ ਪਿਛਲੇ ਬੈਕਅਪ ਤੋਂ ਬਾਅਦ ਬਦਲ ਗਏ ਸਨ। ਇਹ ਆਵਰਤੀ ਬੈਕਅੱਪ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਸਟੋਰੇਜ-ਕੁਸ਼ਲ ਬਣਾਉਂਦਾ ਹੈ। ਬੈਕਅੱਪ ਕੁੱਲ ਕਲੱਸਟਰ ਦੇ ਨੁਕਸਾਨ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ।

ਬੈਕਅੱਪ ਟੀਚਾ

# Create the S3 credentials secret
kubectl create secret generic longhorn-backup-s3-secret \
  -n longhorn-system \
  --from-literal=AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE \
  --from-literal=AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
  --from-literal=AWS_ENDPOINTS=https://s3.eu-west-1.amazonaws.com

# Set the backup target in Longhorn settings
kubectl -n longhorn-system edit settings.longhorn.io backup-target
# Set value to: s3://longhorn-backups@eu-west-1/

kubectl -n longhorn-system edit settings.longhorn.io backup-target-credential-secret
# Set value to: longhorn-backup-s3-secret

# For GCS backup target
# value: s3://longhorn-backups@us/  (GCS is S3-compatible via interop)
# Or use the GCS JSON key:
kubectl create secret generic longhorn-backup-gcs-secret \
  -n longhorn-system \
  --from-literal=GOOGLE_APPLICATION_CREDENTIALS=/var/longhorn-backup/gcs-key.json \
  --from-file=gcs-key.json=./service-account-key.json

# For Azure Blob backup target
kubectl create secret generic longhorn-backup-azure-secret \
  -n longhorn-system \
  --from-literal=AZBLOB_ACCOUNT_NAME=prodbackupstorage \
  --from-literal=AZBLOB_ACCOUNT_KEY=base64encodedkeyhere

ਵਾਲੀਅਮ ਸਨੈਪਸ਼ਾਟ ਕਲਾਸ ਅਤੇ ਸਨੈਪਸ਼ਾਟ YAML

# VolumeSnapshotClass for Longhorn
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: longhorn-snapshot-vsc
driver: driver.longhorn.io
deletionPolicy: Delete
parameters:
  type: snap
---
# Create a VolumeSnapshot
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: pg-data-snap-before-migration
  namespace: database
spec:
  volumeSnapshotClassName: longhorn-snapshot-vsc
  source:
    persistentVolumeClaimName: pg-data-postgresql-0
---
# Restore a PVC from a snapshot
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pg-data-restored
  namespace: database
spec:
  storageClassName: longhorn-db
  dataSource:
    name: pg-data-snap-before-migration
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

ਆਵਰਤੀ ਬੈਕਅੱਪ ਸਮਾਂ-ਸਾਰਣੀ

# Recurring snapshot job — every 4 hours, retain 6
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: db-snapshot-4h
  namespace: longhorn-system
spec:
  cron: "0 */4 * * *"
  task: snapshot
  retain: 6
  concurrency: 2
  groups:
    - db-volumes
  labels:
    tier: database
---
# Recurring backup job — daily at 02:00, retain 14 days
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: db-backup-daily
  namespace: longhorn-system
spec:
  cron: "0 2 * * *"
  task: backup
  retain: 14
  concurrency: 2
  groups:
    - db-volumes
  labels:
    tier: database
---
# Recurring backup job — weekly full, retain 8 weeks
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: db-backup-weekly
  namespace: longhorn-system
spec:
  cron: "0 3 * * 0"
  task: backup
  retain: 8
  concurrency: 1
  groups:
    - db-volumes
  labels:
    tier: database
---
# Assign recurring jobs to a volume via labels
# Label the PVC or volume with: recurring-job-group.longhorn.io/db-volumes: enabled
kubectl label pvc pg-data-postgresql-0 -n database \
  recurring-job-group.longhorn.io/db-volumes=enabled

ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ

LonghornDR ਵੋਲਯੂਮ- ਇੱਕ ਸੈਕੰਡਰੀ ਕਲੱਸਟਰ ਵਿੱਚ ਸਟੈਂਡਬਾਏ ਵਾਲੀਅਮਾਂ ਦੁਆਰਾ ਇੱਕ ਬਿਲਟ-ਇਨ ਡਿਜ਼ਾਸਟਰ ਰਿਕਵਰੀ ਵਿਧੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਪ੍ਰਾਇਮਰੀ ਕਲੱਸਟਰ ਦੇ ਬੈਕਅੱਪ ਟੀਚੇ ਤੋਂ ਲਗਾਤਾਰ ਵਾਧੇ ਵਾਲੇ ਬੈਕਅਪ ਨੂੰ ਖਿੱਚਦਾ ਹੈ। ਜਦੋਂ ਆਫ਼ਤ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ DR ਵਾਲੀਅਮ ਨੂੰ ਸਰਗਰਮ ਕਰਦੇ ਹੋ ਅਤੇ ਇਹ ਇੱਕ ਨਿਯਮਤ ਰੀਡ-ਰਾਈਟ ਵਾਲੀਅਮ ਬਣ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸੈਕੰਡਰੀ ਕਲੱਸਟਰ ਨੂੰ ਸੰਭਾਲਿਆ ਜਾਂਦਾ ਹੈ।

DR ਵਾਲਿਊਮ

# On the DR cluster: create a DR volume from the primary's backup
# This is done via the Longhorn UI or API

# 1. Configure the DR cluster's backup target to point to the same S3 bucket
kubectl -n longhorn-system edit settings.longhorn.io backup-target
# value: s3://longhorn-backups@eu-west-1/

# 2. Create a DR volume from the latest backup
# Via Longhorn UI: Backup → Select volume → Create DR Volume
# Via kubectl:
apiVersion: longhorn.io/v1beta2
kind: Volume
metadata:
  name: pg-data-dr
  namespace: longhorn-system
spec:
  size: "107374182400"  # 100Gi in bytes
  numberOfReplicas: 3
  fromBackup: "s3://longhorn-backups@eu-west-1/?backup=backup-abc123&volume=pg-data"
  standby: true
  frontend: ""

# 3. The DR volume auto-syncs incremental backups from S3
# Monitor sync status:
kubectl -n longhorn-system get volumes.longhorn.io pg-data-dr -o jsonpath='{.status.lastBackup}'

# 4. During failover — activate the DR volume:
kubectl -n longhorn-system patch volumes.longhorn.io pg-data-dr \
  --type merge -p '{"spec":{"standby":false,"frontend":"blockdev"}}'

# 5. Create a PVC bound to the activated DR volume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pg-data-postgresql-0
  namespace: database
spec:
  storageClassName: longhorn-db
  volumeName: pg-data-dr
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

ਵਾਲੀਅਮ ਐਨਕ੍ਰਿਪਸ਼ਨ

Longhorn Linux LUKS2 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਵਾਲੀਅਮ-ਪੱਧਰ ਦੀ ਇਨਕ੍ਰਿਪਸ਼ਨ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਏਨਕ੍ਰਿਪਟਡ ਵਾਲੀਅਮ ਅੰਡਰਲਾਈੰਗ ਡਿਸਕ 'ਤੇ ਬਾਕੀ ਦੇ ਡੇਟਾ ਦੀ ਰੱਖਿਆ ਕਰਦੇ ਹਨ - ਭਾਵੇਂ ਕੋਈ ਵਿਅਕਤੀ ਸਰਵਰ ਦੇ ਸਟੋਰੇਜ ਤੱਕ ਭੌਤਿਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਉਹ ਐਨਕ੍ਰਿਪਸ਼ਨ ਕੁੰਜੀ ਤੋਂ ਬਿਨਾਂ ਵਾਲੀਅਮ ਡੇਟਾ ਨੂੰ ਨਹੀਂ ਪੜ੍ਹ ਸਕਦਾ ਹੈ।

# Create a Kubernetes secret with the encryption passphrase
kubectl create secret generic longhorn-crypto \
  -n longhorn-system \
  --from-literal=CRYPTO_KEY_VALUE="a-very-long-and-random-passphrase-here" \
  --from-literal=CRYPTO_KEY_PROVIDER=secret \
  --from-literal=CRYPTO_KEY_CIPHER=aes-xts-plain64 \
  --from-literal=CRYPTO_KEY_HASH=sha256 \
  --from-literal=CRYPTO_KEY_SIZE=256 \
  --from-literal=CRYPTO_PBKDF=argon2i

# StorageClass with encryption enabled
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-encrypted
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Retain
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880"
  fromBackup: ""
  encrypted: "true"
  csi.storage.k8s.io/provisioner-secret-name: longhorn-crypto
  csi.storage.k8s.io/provisioner-secret-namespace: longhorn-system
  csi.storage.k8s.io/node-publish-secret-name: longhorn-crypto
  csi.storage.k8s.io/node-publish-secret-namespace: longhorn-system
  csi.storage.k8s.io/node-stage-secret-name: longhorn-crypto
  csi.storage.k8s.io/node-stage-secret-namespace: longhorn-system

ReadWriteMany (RWX) ਸਮਰਥਨ

ਮੂਲ ਰੂਪ ਵਿੱਚ, ਲੋਂਗਹੋਰਨ ਵਾਲੀਅਮ ReadWriteOnce (RWO) ਹਨ — ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਪੋਡ ਦੁਆਰਾ ਇੱਕ ਸਿੰਗਲ ਨੋਡ ਉੱਤੇ ਮਾਊਂਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਵਰਕਲੋਡਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਮਲਟੀਪਲ ਪੌਡਾਂ (ਉਦਾਹਰਨ ਲਈ, ਸ਼ੇਅਰਡ ਮੀਡੀਆ ਅੱਪਲੋਡ, ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਾਈਲਾਂ, ML ਮਾਡਲ ਕਲਾਕ੍ਰਿਤੀਆਂ) ਵਿੱਚ ਸਾਂਝੀ ਸਟੋਰੇਜ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਲੋਂਗਹੋਰਨ ਇੱਕ ਏਕੀਕ੍ਰਿਤ NFS ਸਰਵਰ ਦੁਆਰਾ ReadWriteMany (RWX) ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

ਜਦੋਂ ਇੱਕ PVC RWX ਐਕਸੈਸ ਮੋਡ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ, ਤਾਂ Longhorn ਆਪਣੇ ਆਪ ਇੱਕ ਸ਼ੇਅਰ-ਮੈਨੇਜਰ ਪੋਡ ਨੂੰ ਤੈਨਾਤ ਕਰਦਾ ਹੈ ਜੋ Longhorn ਵਾਲੀਅਮ ਦੁਆਰਾ ਸਮਰਥਿਤ NFS ਸਰਵਰ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ। ਮਲਟੀਪਲ ਪੌਡ NFS ਉੱਤੇ ਇੱਕੋ ਸਮੇਂ ਵਾਲੀਅਮ ਨੂੰ ਮਾਊਂਟ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਇੱਕ ਵੱਖਰੇ NFS ਸਰਵਰ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਨਾਲੋਂ ਸੌਖਾ ਹੈ ਪਰ ਸਿੱਧੀ ਬਲਾਕ ਪਹੁੰਚ ਦੇ ਮੁਕਾਬਲੇ ਨੈੱਟਵਰਕ ਓਵਰਹੈੱਡ ਦੀ ਇੱਕ ਪਰਤ ਜੋੜਦਾ ਹੈ।

# PVC with ReadWriteMany access mode
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-media
  namespace: application
spec:
  storageClassName: longhorn-rwx
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 50Gi

ਡਾਟਾਬੇਸ ਵਰਕਲੋਡਸ ਲੌਂਗਹੋਰਨ 'ਤੇ

ਚੱਲ ਰਹੇ ਡੇਟਾਬੇਸ ਲਈ ਸਟੋਰੇਜ ਕਲਾਸ ਪੈਰਾਮੀਟਰਾਂ, ਪੌਡ ਐਫੀਨਿਟੀ, ਅਤੇ ਬੈਕਅੱਪ ਏਕੀਕਰਣ ਵੱਲ ਧਿਆਨ ਦੇਣ ਦੀ ਲੋੜ ਹੈ। ਲੋਂਗਹੋਰਨ ਦਾ ਪ੍ਰਤੀ-ਵਾਲੀਅਮ ਇੰਜਣ ਅਤੇ ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਇਸ ਨੂੰ ਡੇਟਾਬੇਸ ਵਰਕਲੋਡ ਲਈ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲ ਬਣਾਉਂਦੀ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਉਤਪਾਦਨ-ਗਰੇਡ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇਸਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

Longhorn

PostgreSQL ਸਟੇਟਫੁੱਲ ਸੈੱਟ

# PostgreSQL StatefulSet using Longhorn PVC
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgresql
  namespace: database
spec:
  serviceName: postgresql
  replicas: 3
  selector:
    matchLabels:
      app: postgresql
  template:
    metadata:
      labels:
        app: postgresql
    spec:
      terminationGracePeriodSeconds: 120
      securityContext:
        fsGroup: 999
        runAsUser: 999
      containers:
        - name: postgresql
          image: postgres:16-alpine
          ports:
            - containerPort: 5432
          env:
            - name: POSTGRES_DB
              value: production
            - name: POSTGRES_USER
              valueFrom:
                secretKeyRef:
                  name: pg-credentials
                  key: username
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: pg-credentials
                  key: password
            - name: PGDATA
              value: /var/lib/postgresql/data/pgdata
          resources:
            requests:
              cpu: "1"
              memory: 2Gi
            limits:
              cpu: "4"
              memory: 8Gi
          volumeMounts:
            - name: pg-data
              mountPath: /var/lib/postgresql/data
          livenessProbe:
            exec:
              command: ["pg_isready", "-U", "$(POSTGRES_USER)"]
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            exec:
              command: ["pg_isready", "-U", "$(POSTGRES_USER)"]
            initialDelaySeconds: 5
            periodSeconds: 5
  volumeClaimTemplates:
    - metadata:
        name: pg-data
        labels:
          recurring-job-group.longhorn.io/db-volumes: enabled
      spec:
        storageClassName: longhorn-db
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 100Gi

Longhorn

MySQL ਸਟੇਟਫੁੱਲ ਸੈੱਟ

# MySQL StatefulSet using Longhorn PVC
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
  namespace: database
spec:
  serviceName: mysql
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      terminationGracePeriodSeconds: 60
      containers:
        - name: mysql
          image: mysql:8.0
          ports:
            - containerPort: 3306
          env:
            - name: MYSQL_ROOT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mysql-credentials
                  key: root-password
            - name: MYSQL_DATABASE
              value: production
          args:
            - "--default-authentication-plugin=mysql_native_password"
            - "--innodb-buffer-pool-size=4G"
            - "--innodb-log-file-size=1G"
            - "--innodb-flush-log-at-trx-commit=1"
            - "--sync-binlog=1"
          resources:
            requests:
              cpu: "1"
              memory: 4Gi
            limits:
              cpu: "4"
              memory: 8Gi
          volumeMounts:
            - name: mysql-data
              mountPath: /var/lib/mysql
  volumeClaimTemplates:
    - metadata:
        name: mysql-data
        labels:
          recurring-job-group.longhorn.io/db-volumes: enabled
      spec:
        storageClassName: longhorn-db
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 200Gi

ਡਾਟਾਬੇਸ ਵਰਕਲੋਡਸ ਲਈ

ਪ੍ਰਦਰਸ਼ਨ ਟਿਊਨਿੰਗ

Longhorn ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਭੌਤਿਕ ਡਿਸਕ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਸਟੋਰੇਜ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਪਰਤ ਜੋੜਦਾ ਹੈ, ਜੋ ਕਿ ਸਿੱਧੀ ਲੋਕਲ ਡਿਸਕ ਪਹੁੰਚ ਦੇ ਮੁਕਾਬਲੇ ਕੁਝ ਲੇਟੈਂਸੀ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਵਰਕਲੋਡਾਂ ਲਈ ਇਹ ਓਵਰਹੈੱਡ ਅਣਗੌਲਿਆ ਹੁੰਦਾ ਹੈ, ਪਰ ਭਾਰੀ ਲਿਖਣ ਦੇ ਪੈਟਰਨਾਂ ਵਾਲੇ ਡੇਟਾਬੇਸ ਵਰਕਲੋਡ ਨੂੰ ਅਨੁਕੂਲ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਟਿਊਨਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਡਾਟਾ ਸਥਾਨ ਦੀ ਵਰਤੋਂ ਕਰੋ: ਸਭ ਤੋਂ ਵਧੀਆ ਕੋਸ਼ਿਸ਼।ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਪੋਡ ਦੇ ਸਮਾਨ ਨੋਡ 'ਤੇ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਹੈ, ਭਾਵ NVMe/SSD ਸਪੀਡ 'ਤੇ ਲੋਕਲ ਡਿਸਕ ਨੂੰ ਰੀਡ ਕਰਦਾ ਹੈ। ਰਾਈਟਸ ਅਜੇ ਵੀ ਰਿਮੋਟ ਨੋਡਾਂ 'ਤੇ ਨਕਲ ਕਰਦੇ ਹਨ, ਪਰ ਸਥਾਨਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਰੀਡਜ਼ ਲਈ ਨੈਟਵਰਕ ਰਾਊਂਡ-ਟਰਿੱਪਾਂ ਨੂੰ ਖਤਮ ਕਰਦੀ ਹੈ।

ਡਿਸਕਾਂ ਨੂੰ ਲੋਂਗਹੋਰਨ ਨੂੰ ਸਮਰਪਿਤ ਕਰੋ।OS ਡਿਸਕ ਨੂੰ Longhorn ਡੇਟਾ ਨਾਲ ਸਾਂਝਾ ਨਾ ਕਰੋ। ਸਮਰਪਿਤ NVMe ਜਾਂ SSD ਡਰਾਈਵਾਂ ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ Longhorn ਡਿਸਕਾਂ ਵਜੋਂ ਕੌਂਫਿਗਰ ਕਰੋ। ਇਹ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਅਤੇ ਡਾਟਾਬੇਸ ਵਾਲੀਅਮ ਵਿਚਕਾਰ I/O ਵਿਵਾਦ ਨੂੰ ਰੋਕਦਾ ਹੈ।

# Configure dedicated disks on a node
# Via kubectl (Longhorn node CRD)
kubectl -n longhorn-system edit nodes.longhorn.io worker-01

# Add the dedicated disk under spec.disks:
spec:
  disks:
    default-disk:
      allowScheduling: false  # disable OS disk for Longhorn
      path: /var/lib/longhorn/
      storageReserved: 0
    nvme-data:
      allowScheduling: true
      path: /mnt/nvme-longhorn/
      storageReserved: 10737418240  # 10Gi reserved
      tags:
        - nvme
        - database

ਗਾਰੰਟੀਸ਼ੁਦਾ ਇੰਜਨ ਮੈਨੇਜਰ CPU ਸੈੱਟ ਕਰੋ।Longhorn ਦੀਆਂ ਇੰਜਣ ਪ੍ਰਕਿਰਿਆਵਾਂ I/O ਪ੍ਰੋਸੈਸਿੰਗ ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲਈ CPU ਦੀ ਖਪਤ ਕਰਦੀਆਂ ਹਨ।guaranteedInstanceManagerCPUਸੈਟਿੰਗ ਲੋਂਗਹੋਰਨ ਇੰਸਟੈਂਸ ਮੈਨੇਜਰਾਂ ਲਈ ਨੋਡ CPU ਦਾ ਪ੍ਰਤੀਸ਼ਤ ਰਾਖਵਾਂ ਰੱਖਦੀ ਹੈ, CPU ਲੋਡ ਦੇ ਅਧੀਨ ਭੁੱਖਮਰੀ ਨੂੰ ਰੋਕਦੀ ਹੈ।

ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੀ ਗਿਣਤੀ ਨੂੰ ਟਿਊਨ ਕਰੋ।ਉਹਨਾਂ ਡੇਟਾਬੇਸ ਲਈ ਜਿਹਨਾਂ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰ ਦੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਹੈ (PostgreSQL ਸਟ੍ਰੀਮਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀ, MySQL ਸਮੂਹ ਪ੍ਰਤੀਕ੍ਰਿਤੀ, MongoDB ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੈੱਟ), ਤੁਸੀਂ ਲੋਂਗਹੋਰਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੀ ਗਿਣਤੀ ਨੂੰ 3 ਦੀ ਬਜਾਏ 2 ਤੱਕ ਘਟਾ ਸਕਦੇ ਹੋ। ਡੇਟਾਬੇਸ ਦੀ ਆਪਣੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਡੇਟਾ ਸੁਰੱਖਿਆ ਦੀ ਇੱਕ ਵਾਧੂ ਪਰਤ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਅਤੇ ਘੱਟ ਲਿਖਣ ਦਾ ਮਤਲਬ ਹੈ ਘੱਟ ਲਿਖਣਾ ਅਤੇ ਘੱਟ ਲਿਖਣਾ।

ਛੋਟੇ ਬੇਤਰਤੀਬੇ I/O ਲਈ xfs ਉੱਤੇ ext4 ਦੀ ਵਰਤੋਂ ਕਰੋ।ਜਦੋਂ ਕਿ xfs ਵੱਡੇ ਕ੍ਰਮਵਾਰ ਰਾਈਟਸ ਵਿੱਚ ਉੱਤਮ ਹੁੰਦਾ ਹੈ, ext4 ਆਮ ਤੌਰ 'ਤੇ ਡੇਟਾਬੇਸ ਵਰਕਲੋਡ ਦੇ ਛੋਟੇ ਬੇਤਰਤੀਬੇ I/O ਪੈਟਰਨ ਲਈ ਬਿਹਤਰ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦਾ ਹੈ। ਆਪਣੀ ਸਟੋਰੇਜ ਕਲਾਸ ਵਿੱਚfsType: ext4ਸੈੱਟ ਕਰੋ।

ਨੋਡ ਸ਼ਡਿਊਲਿੰਗ ਅਤੇ ਡਿਸਕ ਪ੍ਰਬੰਧਨ

ਲੌਂਗਹੋਰਨ ਵਧੀਆ ਨਿਯੰਤਰਣ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜਿਸ ਉੱਤੇ ਨੋਡ ਅਤੇ ਡਿਸਕਾਂ ਦੀ ਵਰਤੋਂ ਵਾਲੀਅਮ ਸਮਾਂ-ਸਾਰਣੀ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਵਿਪਰੀਤ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਿੱਥੇ ਕੁਝ ਨੋਡਾਂ ਵਿੱਚ ਤੇਜ਼ NVMe ਸਟੋਰੇਜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਬਾਕੀਆਂ ਵਿੱਚ ਹੌਲੀ SATA ਡਰਾਈਵਾਂ ਹੁੰਦੀਆਂ ਹਨ।

# Tag nodes for storage scheduling
kubectl label node worker-01 node.longhorn.io/storage=nvme
kubectl label node worker-02 node.longhorn.io/storage=nvme
kubectl label node worker-03 node.longhorn.io/storage=nvme
kubectl label node worker-04 node.longhorn.io/storage=sata

# Use node selector in StorageClass to target NVMe nodes
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-nvme
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  nodeSelector: "node.longhorn.io/storage=nvme"
  diskSelector: "nvme,database"
  dataLocality: best-effort

ਨਿਗਰਾਨੀ

Longhorn ਇੱਕ ਬਿਲਟ-ਇਨ ਮੈਟ੍ਰਿਕਸ ਐਂਡਪੁਆਇੰਟ ਰਾਹੀਂ Prometheus ਮੈਟ੍ਰਿਕਸ ਦਾ ਪਰਦਾਫਾਸ਼ ਕਰਦਾ ਹੈ। ਸਮਰੱਥਾ ਦੀ ਯੋਜਨਾਬੰਦੀ, ਪ੍ਰਦਰਸ਼ਨ ਵਿਸ਼ਲੇਸ਼ਣ, ਅਤੇ ਕਿਰਿਆਸ਼ੀਲ ਚੇਤਾਵਨੀ ਲਈ ਇਹਨਾਂ ਮੈਟ੍ਰਿਕਸ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ।

# ServiceMonitor for Longhorn metrics
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: longhorn-prometheus
  namespace: monitoring
  labels:
    release: prometheus
spec:
  selector:
    matchLabels:
      app: longhorn-manager
  namespaceSelector:
    matchNames:
      - longhorn-system
  endpoints:
    - port: manager
      path: /metrics
      interval: 30s
---
# PrometheusRule for Longhorn alerts
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: longhorn-alerts
  namespace: monitoring
spec:
  groups:
    - name: longhorn-storage
      rules:
        - alert: LonghornVolumeStatusCritical
          expr: longhorn_volume_robustness == 3
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Longhorn volume {{ $labels.volume }} is Faulted"
        - alert: LonghornVolumeStatusDegraded
          expr: longhorn_volume_robustness == 2
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "Longhorn volume {{ $labels.volume }} is Degraded"
        - alert: LonghornNodeStorageWarning
          expr: |
            (longhorn_node_storage_usage_bytes / longhorn_node_storage_capacity_bytes) > 0.80
          for: 15m
          labels:
            severity: warning
          annotations:
            summary: "Longhorn node {{ $labels.node }} storage at {{ $value | humanizePercentage }}"
        - alert: LonghornBackupFailed
          expr: longhorn_backup_state == 3
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Longhorn backup failed for volume {{ $labels.volume }}"

Longhorn ਨਿਗਰਾਨੀ ਲਈ ਬਣਾਉਣ ਲਈ

ਕੁੰਜੀ Grafana ਡੈਸ਼ਬੋਰਡ ਪੈਨਲਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ: ਵਾਲੀਅਮ IOPS (ਪੜ੍ਹਨ/ਲਿਖਣ), ਵਾਲੀਅਮ ਥ੍ਰੋਪੁੱਟ (MB/s), ਵੌਲਯੂਮ ਲੇਟੈਂਸੀ (p50/p95/p99), ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਰੀਬਿਲਡ ਪ੍ਰਗਤੀ, ਨੋਡ ਸਟੋਰੇਜ ਸਮਰੱਥਾ ਅਤੇ ਵਰਤੋਂ, ਬੈਕਅੱਪ ਸਥਿਤੀ ਅਤੇ ਉਮਰ, ਅਤੇ ਪ੍ਰਤੀ ਵਾਲੀਅਮ ਪ੍ਰਤੀ ਸਨੈਪਸ਼ਾਟ ਗਿਣਤੀ।

k3s ਕਲੱਸਟਰ ਪੂਰੇ ਲੋਂਗਹੋਰਨ ਸਟੋਰੇਜ ਸਟੈਕ ਨਾਲ

ਨਿਮਨਲਿਖਤ ਚਿੱਤਰ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਲੋਂਗਹੋਰਨ ਇੱਕ ਸੰਪੂਰਨ k3s ਉਤਪਾਦਨ ਸਟੈਕ ਵਿੱਚ ਫਿੱਟ ਬੈਠਦਾ ਹੈ, ਬੇਅਰ ਮੈਟਲ ਸਰਵਰਾਂ ਤੋਂ ਲੈ ਕੇ ਐਪਲੀਕੇਸ਼ਨ ਪੌਡ ਤੱਕ, ਰੈਂਚਰ ਪ੍ਰਬੰਧਨ ਅਤੇ Prometheus/Grafana ਨਿਰੀਖਣਯੋਗਤਾ ਦੇ ਨਾਲ।

ਹੋਰ Kubernetes ਸਟੋਰੇਜ਼ ਹੱਲਾਂ ਨਾਲ ਤੁਲਨਾ

Longhorn Kubernetes ਲਈ ਇੱਕੋ ਇੱਕ ਸਟੋਰੇਜ ਵਿਕਲਪ ਨਹੀਂ ਹੈ। ਇਹ ਸਮਝਣਾ ਕਿ ਇਹ ਵਿਕਲਪਾਂ ਨਾਲ ਕਿਵੇਂ ਤੁਲਨਾ ਕਰਦਾ ਹੈ ਤੁਹਾਡੀਆਂ ਖਾਸ ਲੋੜਾਂ ਲਈ ਸਹੀ ਚੋਣ ਕਰਨ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰਦਾ ਹੈ।

Longhorn ਬਨਾਮ Rook-Ceph:Ceph ਵਧੇਰੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸਿਸਟਮ ਹੈ — ਇਹ ਇੱਕ ਵਧੀਆ CRUSH ਪਲੇਸਮੈਂਟ ਐਲਗੋਰਿਦਮ ਨਾਲ ਆਬਜੈਕਟ ਸਟੋਰੇਜ, ਫਾਈਲ ਸਟੋਰੇਜ, ਅਤੇ ਬਲਾਕ ਸਟੋਰੇਜ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, Ceph ਘੱਟੋ-ਘੱਟ 3 ਸਮਰਪਿਤ OSD ਨੋਡਸ, ਮਹੱਤਵਪੂਰਨ RAM (ਘੱਟੋ-ਘੱਟ 4GB ਪ੍ਰਤੀ OSD ਡੈਮਨ), ਅਤੇ ਡੂੰਘੀ ਸੰਚਾਲਨ ਮਹਾਰਤ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ। 3-10 ਨੋਡਾਂ ਵਾਲੇ k3s ਕਲੱਸਟਰਾਂ ਲਈ, ਲੋਂਗਹੋਰਨ ਸੰਚਾਲਨ ਲਾਗਤ ਦੇ 10% 'ਤੇ ਮੁੱਲ ਦਾ 90% ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

Longhorn ਬਨਾਮ OpenEBS Mayastor:Mayastor ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲਈ NVMe-ਓਵਰ-ਫੈਬਰਿਕਸ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਲੋਂਗਹੋਰਨ ਦੀ TCP-ਅਧਾਰਿਤ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨਾਲੋਂ ਘੱਟ ਲੇਟੈਂਸੀ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਕੱਚਾ IOPS ਅਤੇ ਸਬ-ਮਿਲੀਸਕਿੰਟ ਲੇਟੈਂਸੀ ਤੁਹਾਡੀ ਮੁੱਖ ਚਿੰਤਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ RDMA ਨੈੱਟਵਰਕਿੰਗ ਦੇ ਨਾਲ NVMe ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਹੈ, ਤਾਂ Mayastor ਬਿਹਤਰ ਵਿਕਲਪ ਹੋ ਸਕਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ k3s ਤੈਨਾਤੀਆਂ ਲਈ, ਲੋਂਗਹੋਰਨ ਦਾ ਏਕੀਕ੍ਰਿਤ ਬੈਕਅਪ, DR, ਅਤੇ ਕਾਰਜਸ਼ੀਲ ਸਾਦਗੀ ਮੇਅਸਟੋਰ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਕਿਨਾਰੇ ਤੋਂ ਵੱਧ ਹੈ।

ਲੋਂਗਹੋਰਨ ਬਨਾਮ ਲੋਕਲ-ਪਾਥ:ਲੋਕਲ-ਪਾਥ ਪ੍ਰੋਵੀਜ਼ਨਰ k3s ਦੀ ਡਿਫੌਲਟ ਸਟੋਰੇਜ ਹੈ — ਇਹ ਨੋਡ ਦੇ ਲੋਕਲ ਫਾਈਲ ਸਿਸਟਮ 'ਤੇ ਸਿਰਫ਼ ਡਾਇਰੈਕਟਰੀਆਂ ਬਣਾਉਂਦਾ ਹੈ। ਜ਼ੀਰੋ ਪ੍ਰਤੀਕ੍ਰਿਤੀ, ਜ਼ੀਰੋ ਸਨੈਪਸ਼ਾਟ, ਜ਼ੀਰੋ ਬੈਕਅੱਪ ਏਕੀਕਰਣ। ਇਹ ਵਿਕਾਸ ਲਈ ਠੀਕ ਹੈ ਪਰ ਉਤਪਾਦਨ ਡੇਟਾ ਲਈ ਅਸਵੀਕਾਰਨਯੋਗ ਹੈ।

ਉਤਪਾਦਨ ਦੇ ਵਧੀਆ ਅਭਿਆਸ

ਇਹ ਸਿਫ਼ਾਰਿਸ਼ਾਂ ਡਾਟਾਬੇਸ ਵਰਕਲੋਡਾਂ ਨੂੰ ਚਲਾਉਣ ਵਾਲੇ ਦਰਜਨਾਂ ਉਤਪਾਦਨ k3s ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਲੋਂਗਹੋਰਨ ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਡਿਸਟਿਲ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ।

1. ਉਦਾਹਰਣ ਪ੍ਰਬੰਧਕਾਂ ਲਈ ਸਰੋਤ ਰਿਜ਼ਰਵੇਸ਼ਨ ਸੈੱਟ ਕਰੋ।ਲੋਂਗਹੋਰਨ ਇੰਸਟੈਂਸ ਮੈਨੇਜਰਾਂ (ਇੰਜਣ ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਪ੍ਰਬੰਧਕਾਂ) ਨੂੰ ਨੋਡ ਪ੍ਰੈਸ਼ਰ ਦੌਰਾਨ I/O ਸਟਾਲਾਂ ਤੋਂ ਬਚਣ ਲਈ ਗਾਰੰਟੀਸ਼ੁਦਾ CPU ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। Longhorn ਸੈਟਿੰਗਾਂ ਵਿੱਚguaranteedInstanceManagerCPUਨੂੰ ਘੱਟੋ-ਘੱਟ 12% 'ਤੇ ਸੈੱਟ ਕਰੋ।

2. ਡਾਟਾਬੇਸ ਵਾਲੀਅਮ ਲਈ ਰੀਟੇਨ ਰੀਕਲੇਮ ਨੀਤੀ ਦੀ ਵਰਤੋਂ ਕਰੋ।ਡੇਟਾਬੇਸ PVCs ਲਈ ਕਦੇ ਵੀDeleteਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ। ਇੱਕRetainਨੀਤੀ PVC ਦੇ ਮਿਟਾਏ ਜਾਣ ਤੋਂ ਬਾਅਦ ਵੀ PV ਅਤੇ ਇਸਦੇ ਡੇਟਾ ਨੂੰ ਰੱਖਦੀ ਹੈ, ਤੁਹਾਨੂੰ ਦੁਰਘਟਨਾ ਮਿਟਾਏ ਜਾਣ ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਜਾਲ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ।

3. ਉਤਪਾਦਨ ਲਈ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸਾਫਟ ਐਂਟੀ-ਐਫੀਨਿਟੀ ਨੂੰ ਅਸਮਰੱਥ ਬਣਾਓ।replicaSoftAntiAffinity: falseਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਸੈੱਟ ਕਰੋ ਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਹਮੇਸ਼ਾ ਵੱਖ-ਵੱਖ ਨੋਡਾਂ ਵਿੱਚ ਫੈਲੀਆਂ ਹੋਣ। ਨਰਮ ਐਂਟੀ-ਐਫੀਨਿਟੀ ਦੇ ਨਾਲ, ਲੌਂਗਹੋਰਨ ਇੱਕੋ ਨੋਡ 'ਤੇ ਕਈ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨੂੰ ਤਹਿ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਸਪੇਸ ਤੰਗ ਹੁੰਦੀ ਹੈ - ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਉਦੇਸ਼ ਨੂੰ ਹਰਾਉਣਾ।

4. ਹਰ ਨੋਡ 'ਤੇ ਸਟੋਰੇਜ ਸਪੇਸ ਰਿਜ਼ਰਵ ਕਰੋ।storageMinimalAvailablePercentageਨੂੰ ਘੱਟੋ-ਘੱਟ 15% 'ਤੇ ਸੈੱਟ ਕਰੋ। ਇਹ ਲੋਂਗਹੋਰਨ ਨੂੰ ਸਾਰੀ ਡਿਸਕ ਸਪੇਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸਾਰੇ ਪੌਡਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੇ ਨੋਡ-ਪੱਧਰ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ।

5. ਆਟੋ-ਬਚਾਅ ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ।autoSalvageਸੈਟਿੰਗ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਵਾਲੀਅਮ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ ਜੋ ਇੱਕ ਨੁਕਸ ਵਾਲੀ ਸਥਿਤੀ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਜੇ ਵੀ ਸਿਹਤਮੰਦ ਹੁੰਦੀ ਹੈ। ਇਹ ਨੋਡ ਅਸਫਲਤਾਵਾਂ ਦੇ ਦੌਰਾਨ ਦਸਤੀ ਦਖਲ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ.

6. ਤਰਜੀਹੀ ਸ਼੍ਰੇਣੀ ਨੂੰ ਸਿਸਟਮ-ਕਲੱਸਟਰ-ਨਾਜ਼ੁਕ 'ਤੇ ਸੈੱਟ ਕਰੋ।ਲੋਂਗਹੋਰਨ ਦੇ ਮੈਨੇਜਰ ਅਤੇ ਡਰਾਈਵਰ ਕੰਪੋਨੈਂਟ ਨੂੰ ਨੋਡ ਪ੍ਰੈਸ਼ਰ ਦੇ ਦੌਰਾਨ ਕਦੇ ਵੀ ਬੇਦਖਲ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਕਿ ਉਹ ਪੌਡ ਬੇਦਖਲੀ ਤੋਂ ਬਚਣ ਲਈ ਉਹਨਾਂ ਦੀ ਤਰਜੀਹ ਕਲਾਸ ਨੂੰsystem-cluster-critical'ਤੇ ਸੈੱਟ ਕਰੋ।

7. ਸਾਰੇ ਉਤਪਾਦਨ ਵਾਲੀਅਮ ਲਈ ਆਵਰਤੀ ਨੌਕਰੀਆਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰੋ।ਹਰੇਕ ਉਤਪਾਦਨ ਵਾਲੀਅਮ ਵਿੱਚ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਬੈਕਅੱਪ ਆਵਰਤੀ ਨੌਕਰੀਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਤਤਕਾਲ ਰੋਲਬੈਕ ਲਈ ਹਰ 4 ਘੰਟਿਆਂ ਬਾਅਦ ਸਨੈਪਸ਼ਾਟ, ਆਫ਼ਤ ਰਿਕਵਰੀ ਲਈ ਰੋਜ਼ਾਨਾ ਬੈਕਅੱਪ।

8. ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ DR ਵਾਲੀਅਮ ਐਕਟੀਵੇਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੋ।ਆਪਣੇ ਸਟੈਂਡਬਾਏ ਕਲੱਸਟਰ ਵਿੱਚ DR ਵੌਲਯੂਮ ਨੂੰ ਸਰਗਰਮ ਕਰਨ ਲਈ ਇੱਕ ਮਹੀਨਾਵਾਰ ਸਮਾਂ-ਸਾਰਣੀ ਬਣਾਓ, ਡੇਟਾ ਦੀ ਇਕਸਾਰਤਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਫੇਲਓਵਰ ਪ੍ਰਕਿਰਿਆ ਦਾ ਅਭਿਆਸ ਕਰੋ। ਇੱਕ DR ਯੋਜਨਾ ਜਿਸਦੀ ਕਦੇ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ ਉਹ ਸਿਰਫ਼ ਦਸਤਾਵੇਜ਼ ਹੈ।

9. ਵਾਲੀਅਮ ਦੀ ਸਿਹਤ ਦੀ ਸਰਗਰਮੀ ਨਾਲ ਨਿਗਰਾਨੀ ਕਰੋ।ਡੀਗਰੇਡ ਅਤੇ ਨੁਕਸਦਾਰ ਵਾਲੀਅਮ, ਨੋਡ ਸਟੋਰੇਜ ਸਮਰੱਥਾ, ਬੈਕਅੱਪ ਉਮਰ, ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਪੁਨਰ-ਨਿਰਮਾਣ ਸਥਿਤੀ ਲਈ Prometheus ਅਲਰਟ ਸੈਟ ਅਪ ਕਰੋ। ਜਦੋਂ ਤੱਕ ਇੱਕ ਉਪਭੋਗਤਾ ਇੱਕ ਹੌਲੀ ਡਾਟਾਬੇਸ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਸਟੋਰੇਜ ਸਮੱਸਿਆ ਘੰਟਿਆਂ ਤੋਂ ਬਣ ਰਹੀ ਹੈ।

10. ਸਮਰਪਿਤ ਸਟੋਰੇਜ ਡਿਸਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ।ਲੋਂਗਹੋਰਨ ਡੇਟਾ ਨੂੰ OS ਡਿਸਕ ਤੋਂ ਵੱਖ ਕਰੋ। ਇਹ I/O ਵਿਵਾਦ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਕਲੀਨਰ ਸਮਰੱਥਾ ਪ੍ਰਬੰਧਨ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਲੋਂਗਹੋਰਨ ਡੇਟਾ ਨਾਲ OS ਡਿਸਕ ਨੂੰ ਭਰਨ ਦੇ ਜੋਖਮ ਤੋਂ ਬਚਦਾ ਹੈ।

ਕਲਾਉਡ-ਵਿਸ਼ੇਸ਼ ਤੈਨਾਤੀ ਮਾਰਗਦਰਸ਼ਨ

AWS — EC2 NVMe ਇੰਸਟੈਂਸ ਸਟੋਰੇਜ

AWS ਤੈਨਾਤੀਆਂ ਲਈ,i3.xlargeਜਾਂi3en.xlargeਉਦਾਹਰਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੋ NVMe ਇੰਸਟੈਂਸ ਸਟੋਰੇਜ ਨਾਲ ਆਉਂਦੀਆਂ ਹਨ। ਇਹ ਪ੍ਰੋਵਿਜ਼ਨ ਕੀਤੇ EBS IOPS ਦੀ ਲਾਗਤ ਦੇ ਇੱਕ ਹਿੱਸੇ 'ਤੇ ਕੱਚੇ NVMe ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਇੰਸਟੈਂਸ ਸਟੋਰੇਜ ਨੂੰ ਫਾਰਮੈਟ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਲੋਂਗਹੋਰਨ ਡਿਸਕ ਵਜੋਂ ਕੌਂਫਿਗਰ ਕਰੋ।

# On each EC2 i3.xlarge instance
sudo mkfs.ext4 /dev/nvme0n1
sudo mkdir -p /mnt/longhorn-nvme
sudo mount /dev/nvme0n1 /mnt/longhorn-nvme
echo '/dev/nvme0n1 /mnt/longhorn-nvme ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab

# Configure as Longhorn disk (via node CRD or UI)
# Path: /mnt/longhorn-nvme/

Azure — ਅਲਟਰਾ ਡਿਸਕ

Azure 'ਤੇ, ਸਥਾਨਕ NVMe ਸਟੋਰੇਜ ਦੇ ਨਾਲStandard_L8s_v3ਜਾਂStandard_L16s_v3VM ਦੀ ਵਰਤੋਂ ਕਰੋ। ਵਿਕਲਪਿਕ ਤੌਰ 'ਤੇ, ਇਕਸਾਰ ਸਬ-ਮਿਲੀਸਕਿੰਟ ਲੇਟੈਂਸੀ ਲਈ ਅਲਟਰਾ ਡਿਸਕਾਂ ਨੂੰ ਜੋੜੋ। ਅਲਟਰਾ ਡਿਸਕ ਤੁਹਾਨੂੰ IOPS ਅਤੇ ਥ੍ਰੁਪੁੱਟ ਨੂੰ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਸੰਰਚਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਹਨ।

# Attach Ultra Disk to Azure VM (Azure CLI)
az vm disk attach \
  --vm-name k3s-worker-01 \
  --resource-group k3s-cluster \
  --name longhorn-ultra-01 \
  --size-gb 512 \
  --sku UltraSSD_LRS \
  --disk-iops-read-write 10000 \
  --disk-mbps-read-write 300 \
  --new

GCP — ਸਥਾਨਕ SSD

GCPn2-standardਜਾਂc3-standardVMs ਨਾਲ ਜੁੜੇ ਸਥਾਨਕ SSD ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ। ਸਥਾਨਕ SSDs 680,000 ਰੀਡ IOPS ਦੇ ਨਾਲ ਪ੍ਰਤੀ ਡਿਸਕ 375 GB ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਮਲਟੀਪਲ ਲੋਕਲ SSD ਨੱਥੀ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵੱਡੇ ਵਾਲੀਅਮ ਲਈ ਰੇਡ ਕਰੋ।

# Create VM with local SSDs (gcloud)
gcloud compute instances create k3s-worker-01 \
  --machine-type=n2-standard-8 \
  --local-ssd=interface=NVME \
  --local-ssd=interface=NVME \
  --zone=europe-west1-b

# RAID two local SSDs for 750GB Longhorn disk
sudo mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/nvme0n1 /dev/nvme0n2
sudo mkfs.ext4 /dev/md0
sudo mkdir -p /mnt/longhorn-nvme
sudo mount /dev/md0 /mnt/longhorn-nvme

ਆਨ-ਪ੍ਰੀਮਿਸਸ ਡੇਟਾਸੈਂਟਰ

ਆਨ-ਪ੍ਰੀਮਿਸਸ ਤੈਨਾਤੀਆਂ ਲਈ, ਲੋਂਗਹੋਰਨ ਲਈ ਸਮਰਪਿਤ NVMe ਜਾਂ SAS SSD ਡਰਾਈਵਾਂ ਵਾਲੇ ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ। OS ਡਿਸਕ ਨੂੰ ਸਟੋਰੇਜ ਡਿਸਕਾਂ ਤੋਂ ਵੱਖ ਕਰੋ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਨੋਡਾਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ 10GbE ਜਾਂ 25GbE ਨੈਟਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰੋ ਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਰੁਕਾਵਟ ਨਾ ਆਵੇ — ਲੋਂਗਹੋਰਨ ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਗਿਣਤੀ ਦੁਆਰਾ ਗੁਣਾ ਕੀਤੇ ਥ੍ਰੁਪੁੱਟ ਨੂੰ ਲਿਖਣ ਲਈ ਨੈਟਵਰਕ ਟ੍ਰੈਫਿਕ ਅਨੁਪਾਤਕ ਬਣਾਉਂਦਾ ਹੈ।

# Typical on-premises server spec for Longhorn k3s node
# CPU: 8+ cores (Xeon or EPYC)
# RAM: 32+ GB
# OS Disk: 256GB SATA SSD (mirrored)
# Longhorn Disk: 2x 1TB NVMe (RAID-1 or individual Longhorn disks)
# Network: 2x 25GbE (bonded, one for application, one for storage)

# Configure dedicated storage network (optional but recommended)
# In Longhorn settings:
# storage-network: kube-system/storage-network-attachment

Longhorn UI ਵਾਕਥਰੂ

ਲੌਂਗਹੋਰਨ ਇੱਕ ਬਿਲਟ-ਇਨ ਵੈੱਬ UI ਦੇ ਨਾਲ ਸ਼ਿਪ ਕਰਦਾ ਹੈ ਜੋ ਵਾਲੀਅਮ, ਸਨੈਪਸ਼ਾਟ, ਬੈਕਅੱਪ, ਨੋਡਸ ਅਤੇ ਸੈਟਿੰਗਾਂ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਇੱਕ ਵਿਜ਼ੂਅਲ ਇੰਟਰਫੇਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਸ ਨੂੰ ਇੰਸਟਾਲੇਸ਼ਨ ਦੌਰਾਨ ਸੰਰਚਿਤ ਇਨਗਰੇਸ ਰਾਹੀਂ ਜਾਂ kubectl ਪੋਰਟ-ਫਾਰਵਰਡ ਰਾਹੀਂ ਐਕਸੈਸ ਕਰੋ।

# Quick access via port-forward
kubectl -n longhorn-system port-forward svc/longhorn-frontend 8080:80
# Open http://localhost:8080 in your browser

UI ਕਈ ਮੁੱਖ ਦ੍ਰਿਸ਼ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ:ਡੈਸ਼ਬੋਰਡਕੁਲ ਸਮਰੱਥਾ, ਵਰਤੀ ਗਈ ਸਪੇਸ, ਅਤੇ ਵਾਲੀਅਮ ਸਥਿਤੀ ਸਮੇਤ ਕਲੱਸਟਰ-ਵਿਆਪਕ ਸਟੋਰੇਜ ਦੀ ਸਿਹਤ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ।ਵਾਲੀਅਮਉਹਨਾਂ ਦੀ ਸਥਿਤੀ (ਸਿਹਤਮੰਦ/ਡੀਗਰੇਡਡ/ਨੁਕਸਦਾਰ), ਆਕਾਰ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਗਿਣਤੀ, ਅਤੇ ਨੱਥੀ ਨੋਡ ਦੇ ਨਾਲ ਸਾਰੀਆਂ ਵਾਲੀਅਮਾਂ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਇਸ ਦ੍ਰਿਸ਼ ਤੋਂ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਵੌਲਯੂਮ ਦਾ ਵਿਸਤਾਰ, ਸਨੈਪਸ਼ਾਟ, ਬੈਕਅੱਪ ਅਤੇ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ।ਨੋਡਹਰੇਕ ਨੋਡ ਦੀ ਸਟੋਰੇਜ਼ ਸੰਰਚਨਾ, ਡਿਸਕ ਵੰਡ, ਅਤੇ ਸਮਾਂ-ਸਾਰਣੀ ਸਥਿਤੀ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ।ਬੈਕਅੱਪਬੈਕਅੱਪ ਟੀਚੇ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਸਾਰੇ ਬੈਕਅੱਪਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਵਾਲੀਅਮ, ਆਕਾਰ, ਅਤੇ ਰਚਨਾ ਦੇ ਸਮੇਂ ਦੇ ਨਾਲ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ।ਸੈਟਿੰਗਸਾਰੇ ਲੋਂਗਹੋਰਨ ਕੌਂਫਿਗਰੇਸ਼ਨ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਵਰਣਨ ਦੇ ਨਾਲ ਉਜਾਗਰ ਕਰਦੀ ਹੈ।

ਆਮ ਸਮੱਸਿਆਵਾਂ ਦਾ ਨਿਪਟਾਰਾ ਕਰਨਾ

ਡੀਗਰੇਡਡ ਵਾਲੀਅਮ

ਇੱਕ ਵੌਲਯੂਮ ਡੀਗਰੇਡਡ ਸਥਿਤੀ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਗੈਰ-ਸਿਹਤਮੰਦ ਹੁੰਦੀਆਂ ਹਨ ਪਰ ਵਾਲੀਅਮ ਅਜੇ ਵੀ ਕਾਰਜਸ਼ੀਲ ਹੁੰਦਾ ਹੈ। ਆਮ ਕਾਰਨਾਂ ਵਿੱਚ ਨੋਡ ਅਸਫਲਤਾ, ਡਿਸਕ ਭਰੀ, ਜਾਂ ਨੈੱਟਵਰਕ ਭਾਗ ਸ਼ਾਮਲ ਹਨ।

# Check volume status
kubectl -n longhorn-system get volumes.longhorn.io -o wide

# Describe the volume for detailed status
kubectl -n longhorn-system describe volumes.longhorn.io pvc-abc123

# Check replica status
kubectl -n longhorn-system get replicas.longhorn.io -l longhornvolume=pvc-abc123

# If a replica is stuck in error state, delete it to trigger rebuild
kubectl -n longhorn-system delete replicas.longhorn.io pvc-abc123-r-12345

# Monitor rebuild progress
kubectl -n longhorn-system get volumes.longhorn.io pvc-abc123 \
  -o jsonpath='{.status.conditions}' | jq

ਵਾਲੀਅਮ ਅਟੈਚਿੰਗ/ਡੀਟੈਚਿੰਗ ਵਿੱਚ ਫਸਿਆ ਹੋਇਆ ਹੈ

# Check engine status
kubectl -n longhorn-system get engines.longhorn.io -l longhornvolume=pvc-abc123

# Check for stuck VolumeAttachment objects
kubectl get volumeattachments | grep pvc-abc123

# Force detach a stuck volume (use cautiously)
kubectl -n longhorn-system patch volumes.longhorn.io pvc-abc123 \
  --type merge -p '{"spec":{"nodeID":""}}'

# If attachment is truly stuck, delete the VolumeAttachment
kubectl delete volumeattachment csi-abc123def456

ਸਪੇਸ ਪ੍ਰੈਸ਼ਰ

# Check node storage usage
kubectl -n longhorn-system get nodes.longhorn.io -o wide

# Identify large snapshots consuming space
kubectl -n longhorn-system get snapshots.longhorn.io -l longhornvolume=pvc-abc123

# Purge old snapshots to reclaim space
# Via Longhorn UI: Volume → Snapshots → Delete unneeded snapshots
# Old snapshots consume space because COW data cannot be freed until the snapshot is deleted

# Check for snapshot data integrity issues
kubectl -n longhorn-system get settings.longhorn.io snapshot-data-integrity

ਅੱਪਗ੍ਰੇਡ ਪ੍ਰਕਿਰਿਆਵਾਂ

ਲੌਂਗਹੋਰਨ ਅੱਪਗ੍ਰੇਡ ਧਿਆਨ ਨਾਲ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ, ਕਿਉਂਕਿ ਸਟੋਰੇਜ ਸਿਸਟਮ ਸਾਰੇ ਸਟੇਟਫੁੱਲ ਵਰਕਲੋਡ ਨੂੰ ਅੰਡਰਪਿਨ ਕਰਦਾ ਹੈ। ਅੱਪਗਰੇਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਮੇਸ਼ਾ ਸਾਰੇ ਨਾਜ਼ੁਕ ਵਾਲੀਅਮਾਂ ਦਾ ਬੈਕਅੱਪ ਲਓ।

# 1. Back up all volumes before upgrade
for vol in $(kubectl -n longhorn-system get volumes.longhorn.io -o jsonpath='{.items[*].metadata.name}'); do
  echo "Backing up $vol"
  kubectl -n longhorn-system patch volumes.longhorn.io $vol \
    --type merge -p '{"spec":{"lastBackupAt":"'$(date -u +"%Y-%m-%dT%H:%M:%SZ")'"}}'
done

# 2. Check current version
kubectl -n longhorn-system get daemonset longhorn-manager -o jsonpath='{.spec.template.spec.containers[0].image}'

# 3. Upgrade via Helm
helm repo update
helm upgrade longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --version 1.7.2 \
  --values longhorn-values.yaml

# 4. Monitor the rolling upgrade
kubectl -n longhorn-system rollout status daemonset/longhorn-manager
kubectl -n longhorn-system rollout status deployment/longhorn-driver-deployer

# 5. Verify all volumes are healthy after upgrade
kubectl -n longhorn-system get volumes.longhorn.io -o custom-columns=NAME:.metadata.name,STATE:.status.state,ROBUSTNESS:.status.robustness

# 6. Longhorn automatically upgrades engines — monitor progress
kubectl -n longhorn-system get engines.longhorn.io -o wide

ਡੇਟਾਬੇਸ ਆਪਰੇਟਰਾਂ ਨਾਲ ਏਕੀਕਰਣ

ਆਧੁਨਿਕ Kubernetes ਡਾਟਾਬੇਸ ਆਪਰੇਟਰ (CloudNativePG, Percona ਓਪਰੇਟਰ, Zalando Postgres ਆਪਰੇਟਰ) Longhorn ਦੇ ਨਾਲ ਸਹਿਜੇ ਹੀ ਕੰਮ ਕਰਦੇ ਹਨ। ਓਪਰੇਟਰ ਡੇਟਾਬੇਸ ਲਾਈਫਸਾਈਕਲ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਲੋਂਗਹੋਰਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀ, ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਬੈਕਅੱਪ ਦੇ ਨਾਲ ਅੰਡਰਲਾਈੰਗ ਸਟੋਰੇਜ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

# CloudNativePG cluster using Longhorn storage
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: production-pg
  namespace: database
spec:
  instances: 3
  storage:
    size: 100Gi
    storageClass: longhorn-db
    pvcTemplate:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 100Gi
  walStorage:
    size: 20Gi
    storageClass: longhorn-fast

  postgresql:
    parameters:
      shared_buffers: "2GB"
      effective_cache_size: "6GB"
      maintenance_work_mem: "512MB"
      wal_buffers: "64MB"
      max_connections: "200"

  backup:
    barmanObjectStore:
      destinationPath: s3://pg-backups/cnpg/
      endpointURL: https://s3.eu-west-1.amazonaws.com
      s3Credentials:
        accessKeyId:
          name: aws-creds
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: aws-creds
          key: SECRET_ACCESS_KEY
      wal:
        compression: gzip
    retentionPolicy: "30d"

  resources:
    requests:
      cpu: "2"
      memory: 4Gi
    limits:
      cpu: "4"
      memory: 8Gi

# Percona XtraDB Cluster with Longhorn storage
apiVersion: pxc.percona.com/v1
kind: PerconaXtraDBCluster
metadata:
  name: production-mysql
  namespace: database
spec:
  crVersion: "1.14.0"
  pxc:
    size: 3
    image: percona/percona-xtradb-cluster:8.0
    resources:
      requests:
        cpu: "2"
        memory: 4Gi
    volumeSpec:
      persistentVolumeClaim:
        storageClassName: longhorn-db
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 200Gi
  backup:
    image: percona/percona-xtradb-cluster-operator:1.14.0-pxc8.0-backup-pxb8.0.35
    storages:
      s3-backup:
        type: s3
        s3:
          bucket: mysql-backups
          region: eu-west-1
          credentialsSecret: aws-creds
    schedule:
      - name: daily-full
        schedule: "0 2 * * *"
        keep: 14
        storageName: s3-backup

ਸਿੱਟਾ

Longhorn k3s ਨੂੰ ਇੱਕ ਹਲਕੇ Kubernetes ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਤੋਂ ਬਦਲਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਕਿਨਾਰੇ ਅਤੇ ਵਿਕਾਸ ਲਈ ਢੁਕਵਾਂ ਹੈ ਇੱਕ ਉਤਪਾਦਨ-ਤਿਆਰ ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਮਿਸ਼ਨ-ਨਾਜ਼ੁਕ ਸਟੇਟਫੁੱਲ ਵਰਕਲੋਡ ਨੂੰ ਚਲਾਉਣ ਦੇ ਸਮਰੱਥ। ਇਸਦਾ ਆਰਕੀਟੈਕਚਰ — ਪ੍ਰਤੀ-ਵਾਲੀਅਮ ਇੰਜਣ, ਸਮਕਾਲੀ ਮਲਟੀ-ਨੋਡ ਰੀਪਲੀਕੇਸ਼ਨ, ਏਕੀਕ੍ਰਿਤ ਸਨੈਪਸ਼ਾਟ ਅਤੇ ਕਲਾਉਡ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਲਈ ਬੈਕਅੱਪ, DR ਵਾਲੀਅਮ, ਵਾਲੀਅਮ ਐਨਕ੍ਰਿਪਸ਼ਨ, ਅਤੇ ਔਨਲਾਈਨ PVC ਵਿਸਤਾਰ — ਐਂਟਰਪ੍ਰਾਈਜ਼-ਗ੍ਰੇਡ ਦੀ ਗੁੰਝਲਤਾ ਤੋਂ ਬਿਨਾਂ ਐਂਟਰਪ੍ਰਾਈਜ਼-ਗ੍ਰੇਡ ਸਟੋਰੇਜ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਉਤਪਾਦਨ ਵਿੱਚ ਲੋਂਗਹੋਰਨ ਨਾਲ ਸਫਲਤਾ ਦੀ ਕੁੰਜੀ ਤਿੰਨ ਗੁਣਾ ਹੈ। ਪਹਿਲਾਂ, ਇਸ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕਰੋ: ਸਮਰਪਿਤ ਸਟੋਰੇਜ ਡਿਸਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ, ਉਚਿਤ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਕਾਰਕ ਅਤੇ ਡੇਟਾ ਸਥਾਨ ਨਿਰਧਾਰਤ ਕਰੋ, ਅਤੇ ਵੱਖ-ਵੱਖ ਵਰਕਲੋਡ ਕਿਸਮਾਂ ਲਈ ਮਕਸਦ-ਬਣਾਇਆ ਸਟੋਰੇਜ ਕਲਾਸਾਂ ਬਣਾਓ। ਦੂਜਾ, ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਆਪਣੇ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਬੈਕਅੱਪ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕਰੋ: ਤੇਜ਼ ਰੋਲਬੈਕ ਲਈ ਆਵਰਤੀ ਸਨੈਪਸ਼ਾਟ, ਆਫ਼ਤ ਰਿਕਵਰੀ ਲਈ S3/GCS/Azure ਲਈ ਰੋਜ਼ਾਨਾ ਬੈਕਅੱਪ, ਅਤੇ ਸਭ ਤੋਂ ਖਰਾਬ ਸਥਿਤੀ ਲਈ ਸਟੈਂਡਬਾਏ ਕਲੱਸਟਰ ਵਿੱਚ DR ਵਾਲੀਅਮ। ਤੀਜਾ, ਹਰ ਚੀਜ਼ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ: ਵਾਲੀਅਮ ਹੈਲਥ, ਨੋਡ ਸਟੋਰੇਜ ਸਮਰੱਥਾ, ਬੈਕਅੱਪ ਉਮਰ, ਅਤੇ ਰੀਪਲੀਕਾ ਰੀਬਿਲਡ ਸਟੇਟਸ — ਸਟੋਰੇਜ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਉਦੋਂ ਤੱਕ ਅਦਿੱਖ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ ਤੱਕ ਉਹ ਵਿਨਾਸ਼ਕਾਰੀ ਨਹੀਂ ਬਣ ਜਾਂਦੀਆਂ।

ਡਾਇਨਾਮਿਕ PVC ਵਿਸਥਾਰ ਉਤਪਾਦਨ ਦੀਆਂ ਘਟਨਾਵਾਂ ਦੇ ਸਭ ਤੋਂ ਆਮ ਸਰੋਤਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ — ਡਿਸਕ ਸਪੇਸ ਖਤਮ ਹੋ ਰਿਹਾ ਹੈ। ਲੋਂਗਹੋਰਨ ਦੇ ਨਾਲ, 50Gi ਤੋਂ 500Gi ਤੱਕ ਡੇਟਾਬੇਸ ਵਾਲੀਅਮ ਦਾ ਵਿਸਤਾਰ ਕਰਨਾ ਜ਼ੀਰੋ ਡਾਊਨਟਾਈਮ ਦੇ ਨਾਲ ਇੱਕ ਸਿੰਗਲ ਕਿਊਬੈਕਟਲ ਕਮਾਂਡ ਹੈ। ਸਮਰੱਥਾ ਥ੍ਰੈਸ਼ਹੋਲਡ 'ਤੇ Prometheus ਚੇਤਾਵਨੀਆਂ ਦੇ ਨਾਲ ਮਿਲਾ ਕੇ, ਤੁਸੀਂ ਵੌਲਯੂਮ ਦੇ ਨਾਜ਼ੁਕ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਸਰਗਰਮੀ ਨਾਲ ਵਧਾ ਸਕਦੇ ਹੋ, ਜਾਂ ਵਿਸਥਾਰ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਵੈਚਲਿਤ ਕਰ ਸਕਦੇ ਹੋ।

ਭਾਵੇਂ ਤੁਸੀਂ k3s 'ਤੇ PostgreSQL, MySQL, MongoDB, ਜਾਂ Redis ਚਲਾ ਰਹੇ ਹੋ — ਬੇਅਰ ਮੈਟਲ ਸਰਵਰਾਂ 'ਤੇ, AWS EC2, Azure VMs, GCP ਉਦਾਹਰਨਾਂ, ਜਾਂ ਆਨ-ਪ੍ਰੀਮਿਸਸ ਡੇਟਾਸੈਂਟਰ ਹਾਰਡਵੇਅਰ — ਲੋਂਗਹੋਰਨ ਸਟੋਰੇਜ ਫਾਊਂਡੇਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਤੁਹਾਡੇ ਡੇਟਾ ਬਾਰੇ ਚਿੰਤਾ ਕਰਨ ਦੀ ਬਜਾਏ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਨ ਦਿੰਦਾ ਹੈ। ਇਸਨੂੰ ਸਥਾਪਿਤ ਕਰੋ, ਇਸਨੂੰ ਕੌਂਫਿਗਰ ਕਰੋ, ਇਸਦੀ ਨਿਗਰਾਨੀ ਕਰੋ, ਅਤੇ ਆਪਣੇ ਉਤਪਾਦਨ ਡੇਟਾ ਨਾਲ ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰੋ।