ਕੀ ਦੋ ਸਾਈਟਾਂ ਵਾਲੇ Kubernetes ਕਲਸਟਰ ਨੂੰ ਤਿੰਨ etcd ਵੋਟਰ ਚਾਹੀਦੇ ਹਨ?
ਦੋ VPN ਸਾਈਟਾਂ ਉੱਤੇ ਤਿੰਨ ਕੰਟਰੋਲ-ਪਲੇਨ ਨੋਡ ਵੱਡੀ ਸਾਈਟ ਬੰਦ ਹੋਣ 'ਤੇ ਅਜੇ ਵੀ ਕੋਰਮ ਗੁਆ ਦਿੰਦੇ ਹਨ। ਅਸਲੀ etcd ਵੋਟਰ ਗਿਣੋ ਅਤੇ ਉਹ ਨੁਕਸਾਨ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਝੱਲਦੇ ਹੋ।
ਤਿੰਨ ਕੰਟਰੋਲ-ਪਲੇਨ VM ਇੱਕ ਮਾੜੀ ਰਾਤ ਤੋਂ ਬਚਣ ਦੇ ਤਿੰਨ ਮੌਕਿਆਂ ਵਰਗੇ ਲੱਗਦੇ ਹਨ। ਪਰ ਉਹ ਨਹੀਂ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਦੋ ਵਿਸ਼ਵਾਸਾਂ ਵਿਚਕਾਰਲਾ ਫ਼ਾਸਲਾ ਹੀ ਇੱਕ ਸਾਫ਼-ਸੁਥਰੇ ਤਿੰਨ-ਨੋਡ ਡਿਜ਼ਾਈਨ ਨੂੰ ਇੱਕ ਕਲਸਟਰ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਜੋ ਇੱਕ ਇਮਾਰਤ ਦੀ ਬਿਜਲੀ ਜਾਣ 'ਤੇ ਲਿਖਤ ਸਵੀਕਾਰ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਸਾਈਟਾਂ ਵਿਚਕਾਰ VPN ਲਿੰਕ ਮਸ਼ੀਨਾਂ ਨੂੰ ਇੱਕ-ਦੂਜੇ ਲਈ ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਸਮੱਸਿਆ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਥਾਂ ਲੁਕਾਉਂਦਾ ਹੈ। ਵੋਟਾਂ ਹਰ etcd ਮੈਂਬਰ ਪਿੱਛੇ ਗਿਣੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਮੈਂਬਰਾਂ ਵਿੱਚੋਂ ਦੋ ਅਜੇ ਵੀ ਇੱਕ ਸਵਿੱਚ, ਇੱਕ UPS ਅਤੇ ਇੱਕ ਅਪਲਿੰਕ ਪਿੱਛੇ ਬੈਠ ਸਕਦੇ ਹਨ।
ਤਿੰਨ ਕੰਟਰੋਲ-ਪਲੇਨ ਨੋਡ, ਇੱਕ ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਡੋਮੇਨ
ਤੁਸੀਂ kubectl get nodes ਚਲਾਉਂਦੇ ਹੋ, ਤਿੰਨ ਕੰਟਰੋਲ-ਪਲੇਨ ਐਂਟਰੀਆਂ ਵੇਖਦੇ ਹੋ ਅਤੇ ਕਲਸਟਰ ਨੂੰ ਉੱਚ ਉਪਲਬਧ ਵਜੋਂ ਦਰਜ ਕਰਦੇ ਹੋ। ਉਹ ਗਿਣਤੀ ਨਿਯੋਜਤ ਕਰਨ ਯੋਗ ਸਮਰੱਥਾ ਦੱਸਦੀ ਹੈ, ਬਚਾਅ ਨਹੀਂ। ਬਾਹਰੀ etcd ਤੋਂ ਬਿਨਾਂ ਰੱਖੇ kubeadm ਵਿੱਚ, ਹਰ ਕੰਟਰੋਲ-ਪਲੇਨ ਨੋਡ ਇੱਕ ਮੈਂਬਰ ਵੀ ਹੋਸਟ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਤਿੰਨ ਨੋਡ ਸੱਚਮੁੱਚ ਤਿੰਨ ਵੋਟਰ ਦਿੰਦੇ ਹਨ। ਕੀ ਉਹ ਵੋਟਰ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ, ਇਹ ਵੱਖਰਾ ਸਵਾਲ ਹੈ ਜਿਸਦਾ ਜਵਾਬ ਨੋਡ ਸੂਚੀ ਨਹੀਂ ਦੇ ਸਕਦੀ।
ਇੱਕ ਹਾਈਪਰਵਾਈਜ਼ਰ 'ਤੇ ਦੋ VM, ਇੱਕ ਬਿਜਲੀ ਸਪਲਾਈ 'ਤੇ ਦੋ ਰੈਕ, ਇੱਕ ISP ਤੋਂ ਦੋ ਅਪਲਿੰਕ: ਹਰ ਜੋੜੀ ਦੋ ਹੋਸਟਨਾਮ ਪਹਿਨੀ ਇੱਕ ਹੀ ਡੋਮੇਨ ਹੈ। ਪਲੇਸਮੈਂਟ ਲਿਖੋ ਅਤੇ ਹਰ ਵੋਟਰ ਕੀ ਸਾਂਝਾ ਕਰਦਾ ਹੈ ਨਿਸ਼ਾਨ ਲਗਾਓ — ਹਾਈਪਰਵਾਈਜ਼ਰ, PDU, ਰੈਕ ਦਾ ਉੱਪਰਲਾ ਸਵਿੱਚ, ਸਟੋਰੇਜ ਐਰੇ, NAT ਡਿਵਾਈਸ, VPN ਕੇਂਦਰਕ। ਫਿਰ ਕਾਗਜ਼ 'ਤੇ ਹਰ ਸਾਂਝੀ ਵਸਤੂ ਹਟਾਓ ਅਤੇ ਬਚੀਆਂ ਵੋਟਾਂ ਦੁਬਾਰਾ ਗਿਣੋ। ਇੱਕ ਫੇਲ੍ਹ ਹੋਏ ਹੋਸਟ ਕਾਰਨ ਦੋ ਵੋਟਰ ਗੁਆਉਣ ਵਾਲਾ ਕਲਸਟਰ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਇੱਕ-ਵੋਟਰ ਕਲਸਟਰ ਸੀ; ਕਿਸੇ ਨੇ ਇਹ ਸਵਾਲ ਅਜੇ ਪੁੱਛਿਆ ਨਹੀਂ ਸੀ।
ਦੋ ਸਾਈਟਾਂ ਦੀ ਵੰਡ ਕੀ ਝੱਲ ਸਕਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ
ਜਦੋਂ ਤਿੰਨ ਵੋਟਰ ਦੋ ਸਾਈਟਾਂ 'ਤੇ ਦੋ ਅਤੇ ਇੱਕ ਵਜੋਂ ਰੱਖੇ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਦੂਜੀ ਸਾਈਟ ਦੇ ਗਾਇਬ ਹੋਣ 'ਤੇ ਵੱਡਾ ਪਾਸਾ ਕੋਰਮ ਰੱਖਦਾ ਹੈ ਅਤੇ ਇੱਕ-ਵੋਟਰ ਪਾਸਾ ਕਦੇ ਨਹੀਂ। ਇਹ ਅਸਮਾਨਤਾ ਗਣਿਤ ਹੈ, ਟਿਊਨਿੰਗ ਨਹੀਂ। ਠੀਕ ਦੋ ਸੁਤੰਤਰ ਸਾਈਟਾਂ 'ਤੇ ਫੈਲਿਆ ਕੋਈ ਵੀ ਬਹੁਮਤ-ਅਧਾਰਿਤ etcd ਕਲਸਟਰ "ਕੋਈ ਵੀ ਸਾਈਟ ਗੁਆਓ ਅਤੇ ਵਚਨਬੱਧ ਰਹੋ" ਪਰਖ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਦੋਵਾਂ ਪਾਸਿਆਂ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਅੱਧ ਤੋਂ ਵੱਧ ਵੋਟਾਂ ਰੱਖਣੀਆਂ ਪੈਣਗੀਆਂ।
ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਇਹ ਵੇਖਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕਿਹੜੀਆਂ ਫੇਲ੍ਹਤਾਂ ਖਰੀਦੀਆਂ ਹਨ। ਹਰ ਕਤਾਰ ਇੰਜ ਪੜ੍ਹੋ: ਜੇ ਅੱਜ ਰਾਤ ਇਹ ਪੂਰੀ ਕਤਾਰ ਗਾਇਬ ਹੋ ਜਾਵੇ, ਤਾਂ ਕੀ ਬਚੇ ਹੋਏ ਲੋਕ ਅਜੇ ਵੀ ਲਿਖਤ ਵਚਨਬੱਧ ਕਰ ਸਕਦੇ ਹਨ?
| What disappears | Voters left | Writes still commit |
|---|---|---|
| Site B, holding voter 3 | 2 of 3 | Yes |
| Site A, holding voters 1 and 2 | 1 of 3 | No |
| One hypervisor carrying any two voters | 1 of 3 | No |
| The inter-site VPN only | 2 of 3 on one side | Only on the majority side |
ਸੁਰੰਗ ਕਦੇ ਵੋਟ ਕਿਉਂ ਨਹੀਂ ਜੋੜਦੀ
VPN ਆਵਾਜਾਈ ਹੈ, ਮੈਂਬਰ ਨਹੀਂ। ਇਹ ਦੂਰ ਦੇ ਵੋਟਰ ਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾ ਸਕਦਾ ਹੈ ਅਤੇ ਵੰਡ ਨੂੰ ਹੌਲੀ ਟਾਈਮਆਊਟ ਵਰਗੀ ਦਿਖਣ ਵਾਲੀ ਚੀਜ਼ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੋਰਮ ਵਿੱਚ ਇਸਦਾ ਪੂਰਾ ਯੋਗਦਾਨ ਇਹੀ ਹੈ। ਇਹ ਜੋ ਜੋੜਦਾ ਹੈ ਉਹ ਖਰਚਾ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਵਚਨਬੱਧਤਾ ਨੂੰ ਲਿੰਕ ਪਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਅਤੇ etcd raft ਲੌਗ ਨੂੰ ਛੂਹਣ ਵਾਲੀਆਂ ਲਿਖਤਾਂ ਵਿੱਚ ਉਹ ਆਉਣ-ਜਾਣ ਦਾ ਭੁਗਤਾਨ ਕਰਦਾ ਹੈ। ਡੋਲਦਾ ਰਸਤਾ ਨਕਲ ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ਾਂ ਅਤੇ ਚੋਣਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਵੰਡਾਂ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਲੋਕ ਜਾਦੂ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਉਹਨਾਂ ਬਾਰੇ ਸਟੀਕ ਰਹੋ। ਜੇ ਲਿੰਕ ਉਦੋਂ ਡਿੱਗਦਾ ਹੈ ਜਦੋਂ ਪੁਰਾਣਾ ਆਗੂ ਇੱਕ-ਵੋਟਰ ਪਾਸੇ ਬੈਠਾ ਹੈ, ਤਾਂ ਉਹ ਪਾਸਾ ਵਚਨਬੱਧ ਨਹੀਂ ਕਰ ਸਕਦਾ ਅਤੇ ਚੋਣ ਸਮਾਂ-ਸੀਮਾ ਖ਼ਤਮ ਹੋਣ 'ਤੇ ਆਗੂ ਅਹੁਦਾ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਜਦਕਿ ਦੋ-ਵੋਟਰ ਪਾਸਾ ਬਦਲ ਚੁਣਦਾ ਹੈ। etcd ਦੀ ਫੇਲ੍ਹਤ ਮੋਡ ਗਾਈਡ ਵਿਵਹਾਰ ਸਿੱਧਾ ਦੱਸਦੀ ਹੈ: ਬਹੁਮਤ ਪਾਸੇ ਜਾਰੀ ਸੇਵਾ, ਅਲੱਗ ਕੀਤੇ ਪਾਸੇ ਕੋਈ ਦੂਜਾ ਲਿਖਣਯੋਗ ਕਲਸਟਰ ਨਹੀਂ।
ਤੁਸੀਂ ਕਿਹੜਾ ਰੁਕਾਵਟ ਖਰੀਦਦੇ ਹੋ ਇਹ ਤੈਅ ਕਰੋ
ਦੋ ਜਮ੍ਹਾਂ ਇੱਕ ਕਾਨੂੰਨੀ ਡਿਜ਼ਾਈਨ ਹੈ ਜਦੋਂ ਸਾਈਟ A ਪ੍ਰਾਇਮਰੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਮੰਨਦੇ ਹੋ ਕਿ ਇਸਨੂੰ ਗੁਆਉਣ ਦਾ ਮਤਲਬ ਕਿਸੇ ਦੇ ਕਾਰਵਾਈ ਕਰਨ ਤੱਕ ਕੰਟਰੋਲ-ਪਲੇਨ ਲਿਖਤਾਂ ਗੁਆਉਣਾ ਹੈ। ਇਸਨੂੰ ਨੁਕਸ ਬਣਾਉਣ ਵਾਲੀ ਗੱਲ ਉਹ ਫੈਸਲਾ ਲੁਕਵਾਂ ਛੱਡਣਾ ਹੈ। ਇਸਨੂੰ ਰਨਬੁੱਕ ਵਿੱਚ ਲਿਖੋ: ਤੁਹਾਡਾ ਕੰਟਰੋਲ ਪਲੇਨ ਕਿਹੜੀ ਸਾਈਟ ਤੋਂ ਬਚਦਾ ਹੈ, ਅਤੇ ਦੂਜੀ ਸਾਈਟ 03:00 ਵਜੇ ਬੰਦ ਹੋਣ 'ਤੇ ਆਪਰੇਟਰ ਕੀ ਕਰਦਾ ਹੈ।
ਜੇ ਲੋੜ ਇਸਦੀ ਥਾਂ "ਕੋਈ ਵੀ ਸਾਈਟ ਫੇਲ੍ਹ ਹੋ ਸਕਦੀ ਹੈ" ਹੈ, ਤਾਂ ਪਲੇਸਮੈਂਟ ਨੂੰ ਹਰ ਸਾਈਟ ਵਿੱਚ ਬਹੁਮਤ ਰੱਖਣਾ ਪਵੇਗਾ, ਅਤੇ ਦੋ ਸਾਈਟਾਂ 'ਤੇ ਤਿੰਨ ਵੋਟਰ ਅਜਿਹਾ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਤੁਸੀਂ ਜਾਂ ਤਾਂ ਸੱਚਮੁੱਚ ਸੁਤੰਤਰ ਤੀਜਾ ਡੋਮੇਨ ਜੋੜਦੇ ਹੋ — ਕਿਸੇ ਹੋਰ ਪ੍ਰਦਾਤਾ ਵਿੱਚ ਛੋਟਾ ਖੇਤਰ ਕੰਮ ਕਰਦਾ ਹੈ ਜੇ ਉੱਥੇ ਦਾ ਰਸਤਾ ਸਥਿਰ ਹੋਵੇ — ਜਾਂ ਵੱਖਰੇ etcd ਨਾਲ ਦੋ ਕਲਸਟਰਾਂ ਵਿੱਚ ਵੰਡੇ ਜਾਂਦੇ ਹੋ ਅਤੇ ਉਸ ਵੰਡ ਦਾ ਚਾਲੂ ਖਰਚਾ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ। ਕੋਈ ਵੀ ਗਵਾਹ ਸ਼ਾਰਟਕੱਟ ਇਸਨੂੰ ਨਹੀਂ ਟਾਲਦਾ: etcd ਵਿੱਚ ਹਲਕਾ ਮਧਿਅਸਥ ਮੈਂਬਰ ਨਹੀਂ, ਇਸ ਲਈ ਤੀਜਾ ਵੋਟਰ ਆਪਣੀਆਂ ਡਿਸਕ, ਮੈਮਰੀ ਅਤੇ ਨੈੱਟਵਰਕ ਲੋੜਾਂ ਵਾਲਾ ਪੂਰਾ ਮੈਂਬਰ ਹੈ। ਡਾਇਗ੍ਰਾਮ 'ਤੇ "ਗਵਾਹ" ਲਿਖਿਆ ਡੱਬਾ ਖਿੱਚਣ ਨਾਲ ਗਵਾਹ ਨਹੀਂ ਬਣਦਾ।
ਕੋਰਮ ਸੇਵਾ ਵਰਗਾ ਨਹੀਂ ਹੈ
etcd ਕੋਰਮ API ਸਰਵਰ ਨੂੰ ਲਿਖਤ ਸਵੀਕਾਰ ਕਰਨ ਦੇ ਸਮਰੱਥ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਰੱਖਦਾ ਉੱਨਾ ਹੀ ਹੈ। ਲੋਡ ਬੈਲੰਸਰ ਦੀਆਂ ਸਿਹਤ ਜਾਂਚਾਂ, ingress, ਸੁਰੰਗ ਰਾਹੀਂ CNI ਪਹੁੰਚ, ਵੌਲਿਊਮ ਜੋੜਨ ਦੇ ਜ਼ੋਨ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨਕਲ ਨੂੰ ਹਰ ਇੱਕ ਨੂੰ ਆਪਣਾ ਜਵਾਬ ਚਾਹੀਦਾ ਹੈ। ਕਲਸਟਰ ਸਾਫ਼ ਬਹੁਮਤ ਰੱਖ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਕੁਝ ਵੀ ਲਾਹੇਵੰਦ ਨਹੀਂ ਦੇ ਸਕਦਾ।
ਫਿਰ ਉਸ ਮੈਂਬਰਸ਼ਿਪ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਜੋ ਤੁਹਾਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਹੈ, ਕਿਉਂਕਿ ਡਾਇਗ੍ਰਾਮ ਖਿਸਕਦੇ ਹਨ:
kubectl -n kube-system get pods -l component=etcd -o wide
kubectl get endpoints kube-apiserver -n default
etcdctl member list -w table
ਮੈਂਬਰ ਸੂਚੀ ਦੀ ਪਲੇਸਮੈਂਟ ਚਿੱਤਰ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਦੋ ਮੈਂਬਰ ਇੱਕੋ ਹੋਸਟ ਜਾਂ ਇੱਕੋ ਰੈਕ 'ਤੇ ਹੱਲ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਗਲਤ ਚਿੱਤਰ ਹੈ, ਕਲਸਟਰ ਨਹੀਂ, ਅਤੇ ਗਲਤ ਟੋਪੋਲੋਜੀ ਦੁਆਲੇ ਆਕਾਰ ਬਦਲਣਾ ਉਸੇ ਰੁਕਾਵਟ ਦਾ ਸਿਰਫ਼ ਮਹਿੰਗਾ ਸੰਸਕਰਣ ਖਰੀਦਦਾ ਹੈ।
ਕਿਸੇ ਵੀ ਤਿੰਨ-ਵੋਟਰ ਡਿਜ਼ਾਈਨ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿਓ: ਕਿੰਨੇ ਵੋਟਰ ਇਕੱਠੇ ਬਿਜਲੀ ਗੁਆਉਂਦੇ ਹਨ, ਕਿਹੜੀ ਸਾਈਟ ਦੇ ਜਾਣ ਨਾਲ ਅਜੇ ਵੀ ਬਹੁਮਤ ਬਚਦਾ ਹੈ, ਸੁਰੰਗ ਡਿੱਗਣ 'ਤੇ ਆਗੂ ਕਿੱਥੇ ਬੈਠਦਾ ਹੈ, ਅਤੇ ਬਚੀ ਸਾਈਟ ਅਜੇ ਵੀ ਕੀ ਕਰ ਸਕਦੀ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ 'ਤੇ ਵੀ "ਪੱਕਾ ਨਹੀਂ" ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਲਸਟਰ ਅਜੇ ਉੱਚ ਉਪਲਬਧ ਨਹੀਂ ਹੈ। ਇਹ ਤਿੰਨ ਮਸ਼ੀਨਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਕਿਸਮਤ ਚੰਗੀ ਰਹੀ।