Yandex.Cloud ਵਿੱਚ ਇੱਕ ਨੈੱਟਵਰਕ ਲੋਡ ਬੈਲੇਂਸਰ ਦਾ ਆਰਕੀਟੈਕਚਰ

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

ਪਹਿਲਾਂ, ਆਓ ਕੁਝ ਸ਼ਰਤਾਂ ਪੇਸ਼ ਕਰੀਏ:

• VIP (ਵਰਚੁਅਲ IP) - ਸੰਤੁਲਨ ਵਾਲਾ IP ਪਤਾ
• ਸਰਵਰ, ਬੈਕਐਂਡ, ਉਦਾਹਰਨ - ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਚਲਾ ਰਹੀ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ
• RIP (ਰੀਅਲ IP) - ਸਰਵਰ IP ਪਤਾ
• ਸਿਹਤ ਜਾਂਚ - ਸਰਵਰ ਦੀ ਤਿਆਰੀ ਦੀ ਜਾਂਚ ਕਰਨਾ
• ਉਪਲਬਧਤਾ ਜ਼ੋਨ, AZ - ਇੱਕ ਡਾਟਾ ਸੈਂਟਰ ਵਿੱਚ ਅਲੱਗ-ਥਲੱਗ ਬੁਨਿਆਦੀ ਢਾਂਚਾ
• ਖੇਤਰ - ਵੱਖ-ਵੱਖ AZs ਦੀ ਇੱਕ ਯੂਨੀਅਨ

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

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

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

ਡਾਟਾ ਪਲੇਨ

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

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

ਸੰਰਚਨਾ ਜਹਾਜ਼

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

ਨਤੀਜੇ ਵਜੋਂ, API ਤੋਂ ਕੰਮ ਬੈਲੇਂਸਰ ਸਰਵਿਸ ਕੰਟਰੋਲਰ ਨੂੰ ਬੇਨਤੀ ਕਰੇਗਾ, ਜੋ ਗੋ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ। ਇਹ ਬੈਲੇਂਸਰਾਂ ਨੂੰ ਜੋੜ ਅਤੇ ਹਟਾ ਸਕਦਾ ਹੈ, ਬੈਕਐਂਡ ਅਤੇ ਸੈਟਿੰਗਾਂ ਦੀ ਰਚਨਾ ਬਦਲ ਸਕਦਾ ਹੈ। 

ਸੇਵਾ Yandex ਡੇਟਾਬੇਸ ਵਿੱਚ ਆਪਣੀ ਸਥਿਤੀ ਨੂੰ ਸਟੋਰ ਕਰਦੀ ਹੈ, ਇੱਕ ਵਿਤਰਿਤ ਪ੍ਰਬੰਧਿਤ ਡੇਟਾਬੇਸ ਜੋ ਤੁਸੀਂ ਜਲਦੀ ਹੀ ਵਰਤਣ ਦੇ ਯੋਗ ਹੋਵੋਗੇ। Yandex.Cloud ਵਿੱਚ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਨੂੰ ਦੱਸਿਆ, ਕੁੱਤੇ ਦੇ ਭੋਜਨ ਦੀ ਧਾਰਨਾ ਲਾਗੂ ਹੁੰਦੀ ਹੈ: ਜੇਕਰ ਅਸੀਂ ਖੁਦ ਸਾਡੀਆਂ ਸੇਵਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਸਾਡੇ ਗਾਹਕ ਵੀ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਖੁਸ਼ ਹੋਣਗੇ। ਯਾਂਡੇਕਸ ਡੇਟਾਬੇਸ ਅਜਿਹੀ ਧਾਰਨਾ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਇੱਕ ਉਦਾਹਰਣ ਹੈ. ਅਸੀਂ ਆਪਣਾ ਸਾਰਾ ਡਾਟਾ YDB ਵਿੱਚ ਸਟੋਰ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਸਾਨੂੰ ਡਾਟਾਬੇਸ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਅਤੇ ਸਕੇਲ ਕਰਨ ਬਾਰੇ ਸੋਚਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ: ਇਹ ਸਮੱਸਿਆਵਾਂ ਸਾਡੇ ਲਈ ਹੱਲ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਸੀਂ ਇੱਕ ਸੇਵਾ ਵਜੋਂ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

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

ਸਿਹਤ ਜਾਂਚ ਕੰਟਰੋਲਰ

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

ਆਓ ਸਿਹਤ ਜਾਂਚਾਂ ਬਾਰੇ ਹੋਰ ਗੱਲ ਕਰੀਏ। ਉਹਨਾਂ ਨੂੰ ਕਈ ਵਰਗਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਆਡਿਟ ਦੇ ਵੱਖ-ਵੱਖ ਸਫਲਤਾ ਦੇ ਮਾਪਦੰਡ ਹੁੰਦੇ ਹਨ। TCP ਜਾਂਚਾਂ ਨੂੰ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮੇਂ ਦੇ ਅੰਦਰ ਸਫਲਤਾਪੂਰਵਕ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। HTTP ਜਾਂਚਾਂ ਲਈ ਇੱਕ ਸਫਲ ਕਨੈਕਸ਼ਨ ਅਤੇ 200 ਸਥਿਤੀ ਕੋਡ ਦੇ ਨਾਲ ਜਵਾਬ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

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

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

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

ਫਰਕ ਇਹ ਹੈ ਕਿ ਗਾਹਕ VIP ਨੂੰ ਬੇਨਤੀਆਂ ਕਰਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਸਿਹਤ ਜਾਂਚ ਹਰੇਕ ਵਿਅਕਤੀਗਤ RIP ਨੂੰ ਬੇਨਤੀਆਂ ਕਰਦੇ ਹਨ। ਇੱਥੇ ਇੱਕ ਦਿਲਚਸਪ ਸਮੱਸਿਆ ਪੈਦਾ ਹੁੰਦੀ ਹੈ: ਅਸੀਂ ਆਪਣੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸਲੇਟੀ IP ਨੈੱਟਵਰਕਾਂ ਵਿੱਚ ਸਰੋਤ ਬਣਾਉਣ ਦਾ ਮੌਕਾ ਦਿੰਦੇ ਹਾਂ। ਆਓ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਇੱਥੇ ਦੋ ਵੱਖ-ਵੱਖ ਕਲਾਉਡ ਮਾਲਕ ਹਨ ਜਿਨ੍ਹਾਂ ਨੇ ਆਪਣੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਬੈਲੇਂਸਰਾਂ ਦੇ ਪਿੱਛੇ ਲੁਕਾਇਆ ਹੈ. ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਕੋਲ ਇੱਕੋ ਪਤਿਆਂ ਦੇ ਨਾਲ 10.0.0.1/24 ਸਬਨੈੱਟ ਵਿੱਚ ਸਰੋਤ ਹਨ। ਤੁਹਾਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਉਹਨਾਂ ਨੂੰ ਵੱਖ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਅਤੇ ਇੱਥੇ ਤੁਹਾਨੂੰ Yandex.Cloud ਵਰਚੁਅਲ ਨੈਟਵਰਕ ਦੀ ਬਣਤਰ ਵਿੱਚ ਡੁਬਕੀ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਵਿੱਚ ਹੋਰ ਵੇਰਵਿਆਂ ਦਾ ਪਤਾ ਲਗਾਉਣਾ ਬਿਹਤਰ ਹੈ ਇਸ ਬਾਰੇ ਤੋਂ ਵੀਡੀਓ: ਕਲਾਊਡ ਇਵੈਂਟ, ਸਾਡੇ ਲਈ ਹੁਣ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ਬਹੁ-ਪੱਧਰੀ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਸੁਰੰਗਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਬਨੈੱਟ ਆਈਡੀ ਦੁਆਰਾ ਵੱਖ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

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

ਉਲਟਾ ਟ੍ਰੈਫਿਕ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਜਾਂਦਾ ਹੈ: ਬੈਲੇਂਸਰ ਦੇਖਦਾ ਹੈ ਕਿ ਮੰਜ਼ਿਲ ਹੈਲਥ ਚੈਕਰਾਂ ਤੋਂ ਇੱਕ ਸਲੇਟੀ ਨੈੱਟਵਰਕ ਹੈ, ਅਤੇ IPv4 ਨੂੰ IPv6 ਵਿੱਚ ਬਦਲਦਾ ਹੈ।

VPP - ਡੇਟਾ ਪਲੇਨ ਦਾ ਦਿਲ

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

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

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

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

n_left_from = frame->n_vectors;
while (n_left_from > 0)
{
    vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
    // ...
    while (n_left_from >= 4 && n_left_to_next >= 2)
    {
        // processing multiple packets at once
        u32 next0 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        u32 next1 = SAMPLE_NEXT_INTERFACE_OUTPUT;
        // ...
        /* Prefetch next iteration. */
        {
            vlib_buffer_t *p2, *p3;

            p2 = vlib_get_buffer (vm, from[2]);
            p3 = vlib_get_buffer (vm, from[3]);

            vlib_prefetch_buffer_header (p2, LOAD);
            vlib_prefetch_buffer_header (p3, LOAD);

            CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
            CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
        }
        // actually process data
        /* verify speculative enqueues, maybe switch current next frame */
        vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                to_next, n_left_to_next,
                bi0, bi1, next0, next1);
    }

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        // processing packets by one
    }

    // processed batch
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

ਇਸ ਲਈ, ਹੈਲਥ ਚੈਕ IPv6 ਉੱਤੇ VPP ਨਾਲ ਗੱਲ ਕਰਦੇ ਹਨ, ਜੋ ਉਹਨਾਂ ਨੂੰ IPv4 ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਇਹ ਗ੍ਰਾਫ ਵਿੱਚ ਇੱਕ ਨੋਡ ਦੁਆਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸਨੂੰ ਅਸੀਂ ਅਲਗੋਰਿਦਮਿਕ NAT ਕਹਿੰਦੇ ਹਾਂ। ਰਿਵਰਸ ਟ੍ਰੈਫਿਕ (ਅਤੇ IPv6 ਤੋਂ IPv4 ਵਿੱਚ ਪਰਿਵਰਤਨ) ਲਈ ਇੱਕੋ ਐਲਗੋਰਿਦਮਿਕ NAT ਨੋਡ ਹੈ।

ਬੈਲੇਂਸਰ ਕਲਾਇੰਟਸ ਤੋਂ ਸਿੱਧਾ ਟ੍ਰੈਫਿਕ ਗ੍ਰਾਫ ਨੋਡਾਂ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ, ਜੋ ਆਪਣੇ ਆਪ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਦੇ ਹਨ। 

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

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

ਲਗਾਤਾਰ ਹੈਸ਼ਿੰਗ

ਅਸੀਂ ਇਸਨੂੰ ਕਿਉਂ ਚੁਣਿਆ ਅਤੇ ਇਹ ਕੀ ਹੈ? ਪਹਿਲਾਂ, ਆਓ ਪਿਛਲੇ ਕੰਮ 'ਤੇ ਵਿਚਾਰ ਕਰੀਏ - ਸੂਚੀ ਵਿੱਚੋਂ ਇੱਕ ਸਰੋਤ ਚੁਣਨਾ. 

ਅਸੰਗਤ ਹੈਸ਼ਿੰਗ ਦੇ ਨਾਲ, ਆਉਣ ਵਾਲੇ ਪੈਕੇਟ ਦੀ ਹੈਸ਼ ਦੀ ਗਣਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਸਰੋਤਾਂ ਦੀ ਸੰਖਿਆ ਦੁਆਰਾ ਇਸ ਹੈਸ਼ ਨੂੰ ਵੰਡਣ ਦੇ ਬਾਕੀ ਬਚੇ ਦੁਆਰਾ ਸੂਚੀ ਵਿੱਚੋਂ ਇੱਕ ਸਰੋਤ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ। ਜਿੰਨਾ ਚਿਰ ਸੂਚੀ ਵਿੱਚ ਕੋਈ ਤਬਦੀਲੀ ਨਹੀਂ ਹੁੰਦੀ, ਇਹ ਸਕੀਮ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ: ਅਸੀਂ ਹਮੇਸ਼ਾਂ ਉਸੇ 5-ਟੂਪਲ ਵਾਲੇ ਪੈਕੇਟ ਉਸੇ ਮੌਕੇ 'ਤੇ ਭੇਜਦੇ ਹਾਂ। ਜੇ, ਉਦਾਹਰਨ ਲਈ, ਕੁਝ ਸਰੋਤਾਂ ਨੇ ਸਿਹਤ ਜਾਂਚਾਂ ਦਾ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ, ਤਾਂ ਹੈਸ਼ ਦੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸੇ ਲਈ ਚੋਣ ਬਦਲ ਜਾਵੇਗੀ। ਕਲਾਇੰਟ ਦੇ TCP ਕਨੈਕਸ਼ਨ ਟੁੱਟ ਜਾਣਗੇ: ਇੱਕ ਪੈਕੇਟ ਜੋ ਪਹਿਲਾਂ ਉਦਾਹਰਨ A ਤੱਕ ਪਹੁੰਚਿਆ ਸੀ, ਉਦਾਹਰਨ B ਤੱਕ ਪਹੁੰਚਣਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ, ਜੋ ਇਸ ਪੈਕੇਟ ਲਈ ਸੈਸ਼ਨ ਤੋਂ ਜਾਣੂ ਨਹੀਂ ਹੈ।

ਇਕਸਾਰ ਹੈਸ਼ਿੰਗ ਵਰਣਿਤ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦੀ ਹੈ। ਇਸ ਧਾਰਨਾ ਨੂੰ ਸਮਝਾਉਣ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਇਹ ਹੈ: ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਰਿੰਗ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਹੈਸ਼ ਦੁਆਰਾ ਸਰੋਤਾਂ ਨੂੰ ਵੰਡਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, IP: ਪੋਰਟ ਦੁਆਰਾ)। ਇੱਕ ਸਰੋਤ ਦੀ ਚੋਣ ਕਰਨਾ ਪਹੀਏ ਨੂੰ ਇੱਕ ਕੋਣ ਦੁਆਰਾ ਮੋੜ ਰਿਹਾ ਹੈ, ਜੋ ਕਿ ਪੈਕੇਟ ਦੇ ਹੈਸ਼ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

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

ਅਸੀਂ ਦੇਖਿਆ ਕਿ ਬੈਲੇਂਸਰ ਅਤੇ ਸਰੋਤਾਂ ਵਿਚਕਾਰ ਸਿੱਧੀ ਆਵਾਜਾਈ ਦਾ ਕੀ ਹੁੰਦਾ ਹੈ. ਆਓ ਹੁਣ ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਨੂੰ ਵੇਖੀਏ. ਇਹ ਚੈਕ ਟ੍ਰੈਫਿਕ ਦੇ ਸਮਾਨ ਪੈਟਰਨ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ - ਐਲਗੋਰਿਦਮਿਕ NAT ਦੁਆਰਾ, ਯਾਨੀ ਕਿ, ਕਲਾਇੰਟ ਟ੍ਰੈਫਿਕ ਲਈ ਰਿਵਰਸ NAT 44 ਦੁਆਰਾ ਅਤੇ ਹੈਲਥ ਚੈਕ ਟ੍ਰੈਫਿਕ ਲਈ NAT 46 ਦੁਆਰਾ। ਅਸੀਂ ਆਪਣੀ ਖੁਦ ਦੀ ਸਕੀਮ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਾਂ: ਅਸੀਂ ਸਿਹਤ ਜਾਂਚ ਟ੍ਰੈਫਿਕ ਅਤੇ ਅਸਲ ਉਪਭੋਗਤਾ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇਕਜੁੱਟ ਕਰਦੇ ਹਾਂ।

ਲੋਡਬੈਲੈਂਸਰ-ਨੋਡ ਅਤੇ ਅਸੈਂਬਲ ਕੀਤੇ ਹਿੱਸੇ

VPP ਵਿੱਚ ਬੈਲੇਂਸਰਾਂ ਅਤੇ ਸਰੋਤਾਂ ਦੀ ਰਚਨਾ ਸਥਾਨਕ ਸੇਵਾ - loadbalancer-node ਦੁਆਰਾ ਰਿਪੋਰਟ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਲੋਡਬੈਲੈਂਸਰ-ਕੰਟਰੋਲਰ ਤੋਂ ਇਵੈਂਟਸ ਦੀ ਸਟ੍ਰੀਮ ਦੀ ਗਾਹਕੀ ਲੈਂਦਾ ਹੈ ਅਤੇ ਮੌਜੂਦਾ VPP ਸਥਿਤੀ ਅਤੇ ਕੰਟਰੋਲਰ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੇ ਟੀਚੇ ਦੀ ਸਥਿਤੀ ਦੇ ਵਿਚਕਾਰ ਅੰਤਰ ਨੂੰ ਪਲਾਟ ਕਰਨ ਦੇ ਯੋਗ ਹੁੰਦਾ ਹੈ। ਸਾਨੂੰ ਇੱਕ ਬੰਦ ਸਿਸਟਮ ਮਿਲਦਾ ਹੈ: API ਤੋਂ ਇਵੈਂਟਸ ਬੈਲੇਂਸ ਕੰਟਰੋਲਰ ਕੋਲ ਆਉਂਦੇ ਹਨ, ਜੋ ਕਿ ਸਰੋਤਾਂ ਦੀ "ਜੀਵਨਤਾ" ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਸਿਹਤ ਜਾਂਚ ਕੰਟਰੋਲਰ ਨੂੰ ਕੰਮ ਸੌਂਪਦਾ ਹੈ। ਇਹ, ਬਦਲੇ ਵਿੱਚ, ਹੈਲਥ-ਚੈੱਕ-ਨੋਡ ਨੂੰ ਕੰਮ ਸੌਂਪਦਾ ਹੈ ਅਤੇ ਨਤੀਜਿਆਂ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਇਹ ਉਹਨਾਂ ਨੂੰ ਬੈਲੇਂਸ ਕੰਟਰੋਲਰ ਨੂੰ ਵਾਪਸ ਭੇਜਦਾ ਹੈ। ਲੋਡਬੈਲੈਂਸਰ-ਨੋਡ ਕੰਟਰੋਲਰ ਤੋਂ ਇਵੈਂਟਾਂ ਦੀ ਗਾਹਕੀ ਲੈਂਦਾ ਹੈ ਅਤੇ VPP ਦੀ ਸਥਿਤੀ ਨੂੰ ਬਦਲਦਾ ਹੈ। ਅਜਿਹੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ, ਹਰੇਕ ਸੇਵਾ ਨੂੰ ਸਿਰਫ਼ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਗੁਆਂਢੀ ਸੇਵਾਵਾਂ ਬਾਰੇ ਕੀ ਜ਼ਰੂਰੀ ਹੈ। ਕੁਨੈਕਸ਼ਨਾਂ ਦੀ ਗਿਣਤੀ ਸੀਮਤ ਹੈ ਅਤੇ ਸਾਡੇ ਕੋਲ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਚਲਾਉਣ ਅਤੇ ਸਕੇਲ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੈ।

ਕਿਹੜੇ ਮੁੱਦਿਆਂ ਤੋਂ ਬਚਿਆ ਗਿਆ ਸੀ?

ਕੰਟਰੋਲ ਪਲੇਨ ਵਿੱਚ ਸਾਡੀਆਂ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ Go ਵਿੱਚ ਲਿਖੀਆਂ ਗਈਆਂ ਹਨ ਅਤੇ ਚੰਗੀ ਸਕੇਲਿੰਗ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ। ਗੋ ਕੋਲ ਡਿਸਟਰੀਬਿਊਟਡ ਸਿਸਟਮ ਬਣਾਉਣ ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਓਪਨ ਸੋਰਸ ਲਾਇਬ੍ਰੇਰੀਆਂ ਹਨ। ਅਸੀਂ ਸਰਗਰਮੀ ਨਾਲ GRPC ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਸਾਰੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਸੇਵਾ ਖੋਜ ਦਾ ਇੱਕ ਓਪਨ ਸੋਰਸ ਲਾਗੂ ਹੁੰਦਾ ਹੈ - ਸਾਡੀਆਂ ਸੇਵਾਵਾਂ ਇੱਕ ਦੂਜੇ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਦੀ ਰਚਨਾ ਨੂੰ ਗਤੀਸ਼ੀਲ ਰੂਪ ਵਿੱਚ ਬਦਲ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ GRPC ਸੰਤੁਲਨ ਨਾਲ ਜੋੜਿਆ ਹੈ। ਮੈਟ੍ਰਿਕਸ ਲਈ, ਅਸੀਂ ਇੱਕ ਓਪਨ ਸੋਰਸ ਹੱਲ ਵੀ ਵਰਤਦੇ ਹਾਂ। ਡੇਟਾ ਪਲੇਨ ਵਿੱਚ, ਸਾਨੂੰ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਇੱਕ ਵੱਡਾ ਸਰੋਤ ਰਿਜ਼ਰਵ ਮਿਲਿਆ: ਇੱਕ ਸਟੈਂਡ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਸੀ ਜਿਸ 'ਤੇ ਅਸੀਂ ਲੋਹੇ ਦੇ ਨੈਟਵਰਕ ਕਾਰਡ ਦੀ ਬਜਾਏ ਇੱਕ VPP ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਾਂ।

ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਹੱਲ

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

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

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

ਸਾਡੀਆਂ ਯੋਜਨਾਵਾਂ

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

ਹਾਲ ਹੀ ਵਿੱਚ, Yandex ਲੋਡ ਬੈਲੈਂਸਰ ਦੀ ਜਨਤਕ ਰਿਲੀਜ਼ ਹੋਈ ਹੈ। ਪੜਚੋਲ ਕਰੋ ਦਸਤਾਵੇਜ਼ ਸੇਵਾ ਲਈ, ਤੁਹਾਡੇ ਲਈ ਸੁਵਿਧਾਜਨਕ ਤਰੀਕੇ ਨਾਲ ਬੈਲੇਂਸਰਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰੋ ਅਤੇ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਵਧਾਓ!

ਸਰੋਤ: www.habr.com