Mail.ru Cloud Solutions ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਵੈਬ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ

ਹੈਲੋ, ਹੈਬਰ! ਮੈਂ ਆਰਟੈਮ ਕਰਾਮੀਸ਼ੇਵ ਹਾਂ, ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਨ ਟੀਮ ਦਾ ਮੁਖੀ Mail.Ru Cloud Solutions (MCS). ਸਾਡੇ ਕੋਲ ਪਿਛਲੇ ਸਾਲ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਨਵੇਂ ਉਤਪਾਦ ਲਾਂਚ ਹੋਏ ਹਨ। ਅਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਸੀ ਕਿ API ਸੇਵਾਵਾਂ ਆਸਾਨੀ ਨਾਲ ਸਕੇਲੇਬਲ, ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ, ਅਤੇ ਉਪਭੋਗਤਾ ਲੋਡ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਵਾਧੇ ਲਈ ਤਿਆਰ ਸਨ। ਸਾਡਾ ਪਲੇਟਫਾਰਮ ਓਪਨਸਟੈਕ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਣਾ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਪ੍ਰਣਾਲੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਸਾਨੂੰ ਕਿਹੜੀਆਂ ਕੰਪੋਨੈਂਟ ਫਾਲਟ ਸਹਿਣਸ਼ੀਲਤਾ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨਾ ਪਿਆ ਸੀ। ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਇਹ ਉਹਨਾਂ ਲਈ ਦਿਲਚਸਪ ਹੋਵੇਗਾ ਜੋ ਓਪਨਸਟੈਕ 'ਤੇ ਉਤਪਾਦ ਵੀ ਵਿਕਸਤ ਕਰਦੇ ਹਨ.

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

ਇਸ ਕਹਾਣੀ ਦਾ ਵੀਡੀਓ ਸੰਸਕਰਣ, ਜਿਸਦਾ ਪ੍ਰਾਇਮਰੀ ਸਰੋਤ ਅਪਟਾਈਮ ਦਿਨ 4 ਕਾਨਫਰੰਸ ਵਿੱਚ ਇੱਕ ਰਿਪੋਰਟ ਸੀ, ਦੁਆਰਾ ਆਯੋਜਿਤ ITSuma, ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਅੱਪਟਾਈਮ ਕਮਿਊਨਿਟੀ ਯੂਟਿਊਬ ਚੈਨਲ 'ਤੇ.

ਭੌਤਿਕ ਆਰਕੀਟੈਕਚਰ ਦੀ ਲਚਕਤਾ

MCS ਕਲਾਉਡ ਦਾ ਜਨਤਕ ਹਿੱਸਾ ਹੁਣ ਦੋ ਟੀਅਰ III ਡੇਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਅਧਾਰਤ ਹੈ, ਉਹਨਾਂ ਦੇ ਵਿਚਕਾਰ 200 Gbit/s ਦੇ ਥ੍ਰੋਪੁੱਟ ਦੇ ਨਾਲ, ਵੱਖ-ਵੱਖ ਰੂਟਾਂ ਦੁਆਰਾ ਭੌਤਿਕ ਪੱਧਰ 'ਤੇ ਰਾਖਵਾਂ, ਇਸਦਾ ਆਪਣਾ ਡਾਰਕ ਫਾਈਬਰ ਹੈ। ਟੀਅਰ III ਭੌਤਿਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਦਾ ਲੋੜੀਂਦਾ ਪੱਧਰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

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

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

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

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

ਭੌਤਿਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਲਚਕਤਾ

ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰ ਦੀ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਲਈ ਕੀ ਵਰਤਦੇ ਹਾਂ

ਸਾਡੀ ਸੇਵਾ ਕਈ ਓਪਨਸੋਰਸ ਭਾਗਾਂ 'ਤੇ ਬਣੀ ਹੈ।

ExaBGP ਇੱਕ ਸੇਵਾ ਹੈ ਜੋ BGP-ਅਧਾਰਿਤ ਡਾਇਨਾਮਿਕ ਰੂਟਿੰਗ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕਈ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦੀ ਹੈ। ਅਸੀਂ ਸਰਗਰਮੀ ਨਾਲ ਇਸਦੀ ਵਰਤੋਂ ਸਾਡੇ ਵਾਈਟਲਿਸਟ ਕੀਤੇ IP ਪਤਿਆਂ ਦੀ ਮਸ਼ਹੂਰੀ ਕਰਨ ਲਈ ਕਰਦੇ ਹਾਂ ਜਿਸ ਰਾਹੀਂ ਉਪਭੋਗਤਾ API ਤੱਕ ਪਹੁੰਚ ਕਰਦੇ ਹਨ।

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

API ਐਪਲੀਕੇਸ਼ਨ - ਪਾਈਥਨ ਵਿੱਚ ਲਿਖੀ ਇੱਕ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ, ਜਿਸ ਨਾਲ ਉਪਭੋਗਤਾ ਆਪਣੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਅਤੇ ਉਸਦੀ ਸੇਵਾ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ।

ਵਰਕਰ ਐਪਲੀਕੇਸ਼ਨ (ਇਸ ਤੋਂ ਬਾਅਦ ਸਿਰਫ਼ ਵਰਕਰ) - ਓਪਨਸਟੈਕ ਸੇਵਾਵਾਂ ਵਿੱਚ, ਇਹ ਇੱਕ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਡੈਮਨ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ API ਕਮਾਂਡਾਂ ਨੂੰ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਡਿਸਕ ਬਣਾਉਣਾ ਵਰਕਰ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਰਚਨਾ ਦੀ ਬੇਨਤੀ ਐਪਲੀਕੇਸ਼ਨ API ਵਿੱਚ ਹੁੰਦੀ ਹੈ।

ਸਟੈਂਡਰਡ ਓਪਨਸਟੈਕ ਐਪਲੀਕੇਸ਼ਨ ਆਰਕੀਟੈਕਚਰ

ਜ਼ਿਆਦਾਤਰ ਸੇਵਾਵਾਂ ਜੋ ਓਪਨਸਟੈਕ ਲਈ ਵਿਕਸਤ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ ਇੱਕ ਸਿੰਗਲ ਪੈਰਾਡਾਈਮ ਦੀ ਪਾਲਣਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀਆਂ ਹਨ। ਇੱਕ ਸੇਵਾ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ 2 ਹਿੱਸੇ ਹੁੰਦੇ ਹਨ: API ਅਤੇ ਵਰਕਰ (ਬੈਕਐਂਡ ਐਗਜ਼ੀਕਿਊਟਰ)। ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ, ਇੱਕ API ਪਾਈਥਨ ਵਿੱਚ ਇੱਕ WSGI ਐਪਲੀਕੇਸ਼ਨ ਹੈ, ਜੋ ਜਾਂ ਤਾਂ ਇੱਕ ਸੁਤੰਤਰ ਪ੍ਰਕਿਰਿਆ (ਡੈਮਨ) ਦੇ ਰੂਪ ਵਿੱਚ ਲਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜਾਂ ਇੱਕ ਰੈਡੀਮੇਡ Nginx ਜਾਂ Apache ਵੈੱਬ ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ। API ਉਪਭੋਗਤਾ ਦੀ ਬੇਨਤੀ 'ਤੇ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ ਅਤੇ ਅਮਲ ਲਈ ਵਰਕਰ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਹੋਰ ਹਦਾਇਤਾਂ ਪਾਸ ਕਰਦਾ ਹੈ। ਟ੍ਰਾਂਸਫਰ ਇੱਕ ਸੁਨੇਹਾ ਬ੍ਰੋਕਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੁੰਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ RabbitMQ, ਬਾਕੀ ਮਾੜੇ ਸਹਿਯੋਗੀ ਹੁੰਦੇ ਹਨ। ਜਦੋਂ ਸੁਨੇਹੇ ਬ੍ਰੋਕਰ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ, ਤਾਂ ਉਹਨਾਂ 'ਤੇ ਕਰਮਚਾਰੀਆਂ ਦੁਆਰਾ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ, ਜੇ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਜਵਾਬ ਵਾਪਸ ਕਰੋ।

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

ਵਰਕਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਗਿਣਤੀ ਬੇਅੰਤ ਹੈ, ਇਸਲਈ API ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਨੂੰ ਵਧਾਉਣ ਲਈ ਬੈਲੇਂਸਰਾਂ ਦੇ ਪਿੱਛੇ ਆਸਾਨੀ ਨਾਲ ਖਿਤਿਜੀ ਸਕੇਲ ਕਰ ਸਕਦਾ ਹੈ।

ਕੁਝ ਸੇਵਾਵਾਂ ਨੂੰ ਸੇਵਾ ਦੇ ਅੰਦਰ ਤਾਲਮੇਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਦੋਂ API ਅਤੇ ਕਰਮਚਾਰੀਆਂ ਵਿਚਕਾਰ ਗੁੰਝਲਦਾਰ ਕ੍ਰਮਵਾਰ ਕਾਰਵਾਈਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਇੱਕ ਸਿੰਗਲ ਕੋਆਰਡੀਨੇਸ਼ਨ ਸੈਂਟਰ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਇੱਕ ਕਲੱਸਟਰ ਸਿਸਟਮ ਜਿਵੇਂ ਕਿ Redis, Memcache, etcd, ਜੋ ਇੱਕ ਕਰਮਚਾਰੀ ਨੂੰ ਦੂਜੇ ਕਰਮਚਾਰੀ ਨੂੰ ਇਹ ਦੱਸਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਇਹ ਕੰਮ ਉਸ ਨੂੰ ਦਿੱਤਾ ਗਿਆ ਹੈ ("ਕਿਰਪਾ ਕਰਕੇ ਇਸਨੂੰ ਨਾ ਲਓ")। ਅਸੀਂ etcd ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ. ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ ਤੇ, ਕਰਮਚਾਰੀ ਸਰਗਰਮੀ ਨਾਲ ਡਾਟਾਬੇਸ ਨਾਲ ਸੰਚਾਰ ਕਰਦੇ ਹਨ, ਉੱਥੋਂ ਜਾਣਕਾਰੀ ਲਿਖਦੇ ਅਤੇ ਪੜ੍ਹਦੇ ਹਨ। ਅਸੀਂ ਇੱਕ ਡੇਟਾਬੇਸ ਵਜੋਂ mariadb ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਜੋ ਕਿ ਇੱਕ ਮਲਟੀਮਾਸਟਰ ਕਲੱਸਟਰ ਵਿੱਚ ਸਥਿਤ ਹੈ।

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

ਪੂਰੀ ਸਕੀਮ ਵਿੱਚ ਕਮਜ਼ੋਰ ਬਿੰਦੂ RabbitMQ ਅਤੇ MariaDB ਹੈ। ਉਹਨਾਂ ਦਾ ਆਰਕੀਟੈਕਚਰ ਇੱਕ ਵੱਖਰੇ ਲੇਖ ਦਾ ਹੱਕਦਾਰ ਹੈ ਇਸ ਲੇਖ ਵਿੱਚ ਮੈਂ API ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ।

ਓਪਨਸਟੈਕ ਐਪਲੀਕੇਸ਼ਨ ਆਰਕੀਟੈਕਚਰ। ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ ਦਾ ਸੰਤੁਲਨ ਅਤੇ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ

ExaBGP ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ HAProxy ਬੈਲੇਂਸਰ ਨੂੰ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਬਣਾਉਣਾ

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

ਪਹਿਲੀ ਸਮੱਸਿਆ ਜਿਸ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਲੋੜ ਸੀ, ਉਹ ਬੈਲੇਂਸਰ ਦੀ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਸੀ। ਸਿਰਫ਼ ਇੱਕ ਬੈਲੇਂਸਰ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨਾ ਅਸਫਲਤਾ ਦਾ ਇੱਕ ਬਿੰਦੂ ਵੀ ਬਣਾਉਂਦਾ ਹੈ: ਬੈਲੇਂਸਰ ਟੁੱਟ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸੇਵਾ ਕਰੈਸ਼ ਹੋ ਜਾਂਦੀ ਹੈ। ਅਜਿਹਾ ਹੋਣ ਤੋਂ ਰੋਕਣ ਲਈ, ਅਸੀਂ ExaBGP ਦੇ ਨਾਲ HAProxy ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ।

ExaBGP ਤੁਹਾਨੂੰ ਸੇਵਾ ਦੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਵਿਧੀ ਲਾਗੂ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਅਸੀਂ HAProxy ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇਸ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਅਤੇ, ਸਮੱਸਿਆਵਾਂ ਦੀ ਸਥਿਤੀ ਵਿੱਚ, BGP ਤੋਂ HAProxy ਸੇਵਾ ਨੂੰ ਅਸਮਰੱਥ ਬਣਾ ਦਿੱਤਾ।

ExaBGP+HAProxy ਸਕੀਮ

1. ਅਸੀਂ ਲੋੜੀਂਦੇ ਸੌਫਟਵੇਅਰ, ExaBGP ਅਤੇ HAProxy ਨੂੰ ਤਿੰਨ ਸਰਵਰਾਂ 'ਤੇ ਸਥਾਪਿਤ ਕਰਦੇ ਹਾਂ।
2. ਅਸੀਂ ਹਰੇਕ ਸਰਵਰ ਉੱਤੇ ਇੱਕ ਲੂਪਬੈਕ ਇੰਟਰਫੇਸ ਬਣਾਉਂਦੇ ਹਾਂ।
3. ਸਾਰੇ ਤਿੰਨ ਸਰਵਰਾਂ 'ਤੇ ਅਸੀਂ ਇਸ ਇੰਟਰਫੇਸ ਨੂੰ ਇੱਕੋ ਸਫੈਦ IP ਐਡਰੈੱਸ ਦਿੰਦੇ ਹਾਂ।
4. ਇੱਕ ਸਫੈਦ IP ਐਡਰੈੱਸ ਨੂੰ ExaBGP ਰਾਹੀਂ ਇੰਟਰਨੈੱਟ 'ਤੇ ਇਸ਼ਤਿਹਾਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

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

HAProxy ਦੇ ਸੰਚਾਲਨ ਜਾਂ ਸਰਵਰ ਦੀ ਅਸਫਲਤਾ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ExaBGP ਰੂਟ ਦੀ ਘੋਸ਼ਣਾ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਟ੍ਰੈਫਿਕ ਆਸਾਨੀ ਨਾਲ ਦੂਜੇ ਸਰਵਰ ਤੇ ਬਦਲ ਜਾਂਦਾ ਹੈ।

ਇਸ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਬੈਲੇਂਸਰ ਦੀ ਗਲਤੀ ਸਹਿਣਸ਼ੀਲਤਾ ਪ੍ਰਾਪਤ ਕੀਤੀ।

HAProxy ਬੈਲੇਂਸਰਾਂ ਦੀ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ

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

DNS ਪਲੱਸ BGP 'ਤੇ ਆਧਾਰਿਤ ਸੰਤੁਲਨ

ਸਾਡੇ HAProxy ਲਈ ਲੋਡ ਸੰਤੁਲਨ ਦਾ ਮੁੱਦਾ ਅਣਸੁਲਝਿਆ ਹੋਇਆ ਹੈ। ਹਾਲਾਂਕਿ, ਇਸ ਨੂੰ ਕਾਫ਼ੀ ਅਸਾਨੀ ਨਾਲ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਇੱਥੇ ਕੀਤਾ ਹੈ.

ਤਿੰਨ ਸਰਵਰਾਂ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ 3 ਚਿੱਟੇ IP ਪਤਿਆਂ ਅਤੇ ਚੰਗੇ ਪੁਰਾਣੇ DNS ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਪਤੇ ਨੂੰ ਹਰੇਕ HAProxy ਦੇ ਲੂਪਬੈਕ ਇੰਟਰਫੇਸ ਤੇ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇੰਟਰਨੈਟ ਤੇ ਇਸ਼ਤਿਹਾਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਓਪਨਸਟੈਕ ਵਿੱਚ, ਸਰੋਤਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ, ਇੱਕ ਸੇਵਾ ਡਾਇਰੈਕਟਰੀ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਕਿਸੇ ਖਾਸ ਸੇਵਾ ਦੇ ਅੰਤਮ ਬਿੰਦੂ API ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਦੀ ਹੈ। ਇਸ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਅਸੀਂ ਇੱਕ ਡੋਮੇਨ ਨਾਮ ਰਜਿਸਟਰ ਕਰਦੇ ਹਾਂ - public.infra.mail.ru, ਜੋ ਕਿ ਤਿੰਨ ਵੱਖ-ਵੱਖ IP ਪਤਿਆਂ ਦੁਆਰਾ DNS ਦੁਆਰਾ ਹੱਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਸਾਨੂੰ DNS ਰਾਹੀਂ ਤਿੰਨ ਪਤਿਆਂ ਵਿਚਕਾਰ ਲੋਡ ਵੰਡ ਮਿਲਦੀ ਹੈ।

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

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

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

DNS + BGP 'ਤੇ ਅਧਾਰਤ HAProxy ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨਾ

ExaBGP ਅਤੇ HAProxy ਵਿਚਕਾਰ ਪਰਸਪਰ ਪ੍ਰਭਾਵ

ਇਸ ਲਈ, ਅਸੀਂ ਰੂਟਾਂ ਦੀ ਘੋਸ਼ਣਾ ਨੂੰ ਰੋਕਣ ਦੇ ਅਧਾਰ ਤੇ, ਸਰਵਰ ਛੱਡਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ। ਪਰ HAProxy ਸਰਵਰ ਅਸਫਲਤਾ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਕਾਰਨਾਂ ਕਰਕੇ ਬੰਦ ਹੋ ਸਕਦਾ ਹੈ: ਪ੍ਰਸ਼ਾਸਨ ਦੀਆਂ ਗਲਤੀਆਂ, ਸੇਵਾ ਦੇ ਅੰਦਰ ਅਸਫਲਤਾਵਾਂ। ਅਸੀਂ ਇਹਨਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਵੀ ਲੋਡ ਦੇ ਹੇਠਾਂ ਤੋਂ ਟੁੱਟੇ ਹੋਏ ਬੈਲੈਂਸਰ ਨੂੰ ਹਟਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਅਤੇ ਸਾਨੂੰ ਇੱਕ ਵੱਖਰੀ ਵਿਧੀ ਦੀ ਲੋੜ ਹੈ।

ਇਸ ਲਈ, ਪਿਛਲੀ ਸਕੀਮ ਦਾ ਵਿਸਤਾਰ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ExaBGP ਅਤੇ HAProxy ਵਿਚਕਾਰ ਦਿਲ ਦੀ ਧੜਕਣ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ। ਇਹ ExaBGP ਅਤੇ HAProxy ਵਿਚਕਾਰ ਆਪਸੀ ਤਾਲਮੇਲ ਦਾ ਇੱਕ ਸਾਫਟਵੇਅਰ ਲਾਗੂਕਰਨ ਹੈ, ਜਦੋਂ ExaBGP ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਕਸਟਮ ਸਕ੍ਰਿਪਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

ਅਜਿਹਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ExaBGP ਸੰਰਚਨਾ ਵਿੱਚ ਇੱਕ ਸਿਹਤ ਜਾਂਚਕਰਤਾ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਜੋ HAProxy ਦੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਅਸੀਂ ਹੈਲਥ ਬੈਕਐਂਡ ਨੂੰ HAProxy ਵਿੱਚ ਕੌਂਫਿਗਰ ਕੀਤਾ ਹੈ, ਅਤੇ ExaBGP ਵਾਲੇ ਪਾਸੇ ਤੋਂ ਅਸੀਂ ਇੱਕ ਸਧਾਰਨ GET ਬੇਨਤੀ ਨਾਲ ਜਾਂਚ ਕਰਦੇ ਹਾਂ। ਜੇਕਰ ਘੋਸ਼ਣਾ ਬੰਦ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ HAProxy ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਇਸਦਾ ਇਸ਼ਤਿਹਾਰ ਦੇਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ।

HAProxy ਸਿਹਤ ਜਾਂਚ

HAProxy Peers: ਸੈਸ਼ਨ ਸਮਕਾਲੀਕਰਨ

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

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

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

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

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

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

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

ਤਸਵੀਰ ਯੋਜਨਾਬੱਧ ਤੌਰ 'ਤੇ ਤਿੰਨ HAProxy ਉਦਾਹਰਨਾਂ ਦੇ ਵਿਚਕਾਰ ਪੀਅਰ ਟੇਬਲ ਦੀ ਗਤੀ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ, ਇੱਕ ਸੰਰਚਨਾ ਪ੍ਰਸਤਾਵਿਤ ਹੈ ਕਿ ਇਸਨੂੰ ਕਿਵੇਂ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

HAProxy Peers (ਸੈਸ਼ਨ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ)

ਜੇਕਰ ਤੁਸੀਂ ਉਹੀ ਸਕੀਮ ਲਾਗੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਸਦੀ ਕਾਰਵਾਈ ਨੂੰ ਧਿਆਨ ਨਾਲ ਜਾਂਚਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਇੱਕ ਤੱਥ ਨਹੀਂ ਹੈ ਕਿ ਇਹ 100% ਸਮੇਂ ਵਿੱਚ ਉਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰੇਗਾ। ਪਰ ਘੱਟੋ-ਘੱਟ ਤੁਸੀਂ ਸਟਿੱਕ ਟੇਬਲ ਨਹੀਂ ਗੁਆਓਗੇ ਜਦੋਂ ਤੁਹਾਨੂੰ ਕਲਾਇੰਟ ਦੇ ਸਰੋਤ IP ਨੂੰ ਯਾਦ ਰੱਖਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਇੱਕੋ ਕਲਾਇੰਟ ਤੋਂ ਇੱਕੋ ਸਮੇਂ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਸੀਮਿਤ ਕਰਨਾ

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

ਇੱਕ ਜਾਂ ਦੂਜੇ ਤਰੀਕੇ ਨਾਲ, ਵਾਧੂ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਸਪੱਸ਼ਟ ਹੱਲ API ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਸੀਮਤ ਕਰਨਾ ਹੈ ਅਤੇ ਖਤਰਨਾਕ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਵਿੱਚ CPU ਸਮਾਂ ਬਰਬਾਦ ਨਹੀਂ ਕਰਨਾ ਹੈ।

ਅਜਿਹੀਆਂ ਪਾਬੰਦੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ, ਅਸੀਂ ਉਸੇ ਸਟਿੱਕ ਟੇਬਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, HAProxy ਦੇ ਆਧਾਰ 'ਤੇ ਸੰਗਠਿਤ ਦਰ ਸੀਮਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਸੀਮਾਵਾਂ ਨੂੰ ਸੈੱਟ ਕਰਨਾ ਕਾਫ਼ੀ ਸਧਾਰਨ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ API ਨੂੰ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਦੁਆਰਾ ਉਪਭੋਗਤਾ ਨੂੰ ਸੀਮਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ. ਐਲਗੋਰਿਦਮ ਸਰੋਤ IP ਨੂੰ ਯਾਦ ਰੱਖਦਾ ਹੈ ਜਿਸ ਤੋਂ ਬੇਨਤੀਆਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਇੱਕ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਇੱਕੋ ਸਮੇਂ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ। ਬੇਸ਼ੱਕ, ਅਸੀਂ ਹਰੇਕ ਸੇਵਾ ਲਈ ਔਸਤ API ਲੋਡ ਪ੍ਰੋਫਾਈਲ ਦੀ ਗਣਨਾ ਕੀਤੀ ਹੈ ਅਤੇ ਇਸ ਮੁੱਲ ਤੋਂ 10 ਗੁਣਾ ≈ ਦੀ ਇੱਕ ਸੀਮਾ ਸੈੱਟ ਕੀਤੀ ਹੈ। ਅਸੀਂ ਸਥਿਤੀ ਦੀ ਨੇੜਿਓਂ ਨਿਗਰਾਨੀ ਕਰਦੇ ਰਹਿੰਦੇ ਹਾਂ ਅਤੇ ਨਬਜ਼ 'ਤੇ ਆਪਣੀ ਉਂਗਲ ਰੱਖਦੇ ਹਾਂ।

ਅਭਿਆਸ ਵਿੱਚ ਇਹ ਕੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ? ਸਾਡੇ ਕੋਲ ਗਾਹਕ ਹਨ ਜੋ ਹਰ ਸਮੇਂ ਸਾਡੇ ਆਟੋਸਕੇਲਿੰਗ API ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਉਹ ਸਵੇਰੇ ਲੱਗਭੱਗ ਦੋ ਤੋਂ ਤਿੰਨ ਸੌ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ ਸ਼ਾਮ ਨੂੰ ਡਿਲੀਟ ਕਰ ਦਿੰਦੇ ਹਨ। ਓਪਨਸਟੈਕ ਲਈ, ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਬਣਾਉਣ ਲਈ, PaaS ਸੇਵਾਵਾਂ ਦੇ ਨਾਲ, ਘੱਟੋ-ਘੱਟ 1000 API ਬੇਨਤੀਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਸੇਵਾਵਾਂ ਵਿਚਕਾਰ ਆਪਸੀ ਤਾਲਮੇਲ API ਦੁਆਰਾ ਵੀ ਹੁੰਦਾ ਹੈ।

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

ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੇ ਬਿਨਾਂ ਆਪਣੇ ਕੋਡਬੇਸ ਨੂੰ ਕਿਵੇਂ ਅਪਡੇਟ ਕਰਨਾ ਹੈ

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

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

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਬੈਲੈਂਸਰ ਦੇ ਨਿਯੰਤਰਣ ਅਤੇ ਸੇਵਾਵਾਂ ਦੇ "ਸਹੀ" ਬੰਦ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ ਜ਼ਰੂਰੀ ਸੀ:

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

ਇਹਨਾਂ ਦੋ ਬਿੰਦੂਆਂ ਲਈ ਧੰਨਵਾਦ, ਸਾਡੀ ਤੈਨਾਤੀ ਲਈ ਸੁਰੱਖਿਅਤ ਐਲਗੋਰਿਦਮ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ.

1. ਡਿਵੈਲਪਰ ਕੋਡ ਦੇ ਇੱਕ ਨਵੇਂ ਪੈਕੇਜ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ (ਸਾਡੇ ਲਈ ਇਹ RPM ਹੈ), ਇਸਨੂੰ dev ਵਾਤਾਵਰਣ ਵਿੱਚ ਟੈਸਟ ਕਰਦਾ ਹੈ, ਇਸਨੂੰ ਪੜਾਅ ਵਿੱਚ ਟੈਸਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਸਟੇਜ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਛੱਡਦਾ ਹੈ।
2. ਡਿਵੈਲਪਰ "ਕਲਾਕਾਰੀ" ਦੇ ਸਭ ਤੋਂ ਵਿਸਤ੍ਰਿਤ ਵਰਣਨ ਦੇ ਨਾਲ ਤੈਨਾਤੀ ਲਈ ਕੰਮ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ: ਨਵੇਂ ਪੈਕੇਜ ਦਾ ਸੰਸਕਰਣ, ਨਵੀਂ ਕਾਰਜਸ਼ੀਲਤਾ ਦਾ ਵੇਰਵਾ ਅਤੇ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਤੈਨਾਤੀ ਬਾਰੇ ਹੋਰ ਵੇਰਵੇ।
3. ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਅੱਪਡੇਟ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਜਵਾਬਦੇਹ ਪਲੇਬੁੱਕ ਲਾਂਚ ਕਰਦਾ ਹੈ, ਜੋ ਬਦਲੇ ਵਿੱਚ ਹੇਠ ਲਿਖੇ ਕੰਮ ਕਰਦਾ ਹੈ:
   • ਸਟੇਜ ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ ਇੱਕ ਪੈਕੇਜ ਲੈਂਦਾ ਹੈ ਅਤੇ ਉਤਪਾਦ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਪੈਕੇਜ ਦੇ ਸੰਸਕਰਣ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਲਈ ਇਸਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।
   • ਅੱਪਡੇਟ ਕੀਤੀ ਸੇਵਾ ਦੇ ਬੈਕਐਂਡ ਦੀ ਸੂਚੀ ਕੰਪਾਇਲ ਕਰਦਾ ਹੈ।
   • HAProxy ਵਿੱਚ ਅੱਪਡੇਟ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਪਹਿਲੀ ਸੇਵਾ ਨੂੰ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇਸ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਚੱਲਣ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ। ਸ਼ਾਨਦਾਰ ਬੰਦ ਕਰਨ ਲਈ ਧੰਨਵਾਦ, ਸਾਨੂੰ ਭਰੋਸਾ ਹੈ ਕਿ ਸਾਰੀਆਂ ਮੌਜੂਦਾ ਕਲਾਇੰਟ ਬੇਨਤੀਆਂ ਸਫਲਤਾਪੂਰਵਕ ਪੂਰੀਆਂ ਹੋਣਗੀਆਂ।
   • API ਅਤੇ ਕਰਮਚਾਰੀਆਂ ਦੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੰਦ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਅਤੇ HAProxy ਬੰਦ ਹੋ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਕੋਡ ਅੱਪਡੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
   • ਜਵਾਬਦੇਹ ਚੱਲਦੀਆਂ ਸੇਵਾਵਾਂ।
   • ਹਰੇਕ ਸੇਵਾ ਲਈ, ਕੁਝ "ਹੈਂਡਲਜ਼" ਖਿੱਚੇ ਜਾਂਦੇ ਹਨ, ਜੋ ਕਿ ਕਈ ਪ੍ਰੀ-ਪ੍ਰਭਾਸ਼ਿਤ ਕੁੰਜੀ ਟੈਸਟਾਂ 'ਤੇ ਯੂਨਿਟ ਟੈਸਟਿੰਗ ਕਰਦੇ ਹਨ। ਨਵੇਂ ਕੋਡ ਦੀ ਮੁੱਢਲੀ ਜਾਂਚ ਹੁੰਦੀ ਹੈ।
   • ਜੇਕਰ ਪਿਛਲੇ ਪਗ ਵਿੱਚ ਕੋਈ ਤਰੁੱਟੀਆਂ ਨਹੀਂ ਮਿਲੀਆਂ, ਤਾਂ ਬੈਕਐਂਡ ਕਿਰਿਆਸ਼ੀਲ ਹੋ ਜਾਂਦਾ ਹੈ।
   • ਆਓ ਅਗਲੇ ਬੈਕਐਂਡ 'ਤੇ ਚੱਲੀਏ।
4. ਸਾਰੇ ਬੈਕਐਂਡ ਅੱਪਡੇਟ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਫੰਕਸ਼ਨਲ ਟੈਸਟ ਲਾਂਚ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਜੇ ਉਹ ਗੁੰਮ ਹਨ, ਤਾਂ ਡਿਵੈਲਪਰ ਉਸ ਦੁਆਰਾ ਬਣਾਈ ਗਈ ਕਿਸੇ ਵੀ ਨਵੀਂ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਵੇਖਦਾ ਹੈ।

ਇਹ ਤੈਨਾਤੀ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ।

ਸੇਵਾ ਅੱਪਡੇਟ ਚੱਕਰ

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

ਸਿੱਟਾ

ਇੱਕ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ WEB ਆਰਕੀਟੈਕਚਰ ਬਾਰੇ ਮੇਰੇ ਆਪਣੇ ਵਿਚਾਰ ਸਾਂਝੇ ਕਰਦੇ ਹੋਏ, ਮੈਂ ਇੱਕ ਵਾਰ ਫਿਰ ਇਸਦੇ ਮੁੱਖ ਨੁਕਤਿਆਂ ਨੂੰ ਨੋਟ ਕਰਨਾ ਚਾਹਾਂਗਾ:

• ਸਰੀਰਕ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ;
• ਨੈੱਟਵਰਕ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ (ਬੈਲੈਂਸਰ, BGP);
• ਵਰਤੇ ਅਤੇ ਵਿਕਸਿਤ ਕੀਤੇ ਗਏ ਸੌਫਟਵੇਅਰ ਦੀ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ।

ਸਥਿਰ ਅਪਟਾਈਮ ਹਰ ਕੋਈ!

ਸਰੋਤ: www.habr.com