Badoo ਨੇ 200k ਫੋਟੋਆਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਭੇਜਣ ਦੀ ਯੋਗਤਾ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕੀਤੀ

ਮੀਡੀਆ ਸਮੱਗਰੀ ਤੋਂ ਬਿਨਾਂ ਆਧੁਨਿਕ ਵੈੱਬ ਲਗਭਗ ਅਸੰਭਵ ਹੈ: ਲਗਭਗ ਹਰ ਦਾਦੀ ਕੋਲ ਇੱਕ ਸਮਾਰਟਫੋਨ ਹੈ, ਹਰ ਕੋਈ ਸੋਸ਼ਲ ਨੈਟਵਰਕਸ 'ਤੇ ਹੈ, ਅਤੇ ਰੱਖ-ਰਖਾਅ ਵਿੱਚ ਡਾਊਨਟਾਈਮ ਕੰਪਨੀਆਂ ਲਈ ਮਹਿੰਗਾ ਹੈ। ਇੱਥੇ ਕੰਪਨੀ ਦੀ ਕਹਾਣੀ ਦੀ ਇੱਕ ਪ੍ਰਤੀਲਿਪੀ ਹੈ Badoo ਇਸ ਬਾਰੇ ਕਿ ਉਸਨੇ ਹਾਰਡਵੇਅਰ ਹੱਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਫੋਟੋਆਂ ਦੀ ਡਿਲੀਵਰੀ ਦਾ ਪ੍ਰਬੰਧ ਕਿਵੇਂ ਕੀਤਾ, ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਉਸਨੂੰ ਕਿਹੜੀਆਂ ਕਾਰਗੁਜ਼ਾਰੀ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ, ਉਹਨਾਂ ਦਾ ਕੀ ਕਾਰਨ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ Nginx 'ਤੇ ਅਧਾਰਤ ਇੱਕ ਸੌਫਟਵੇਅਰ ਹੱਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਿਵੇਂ ਹੱਲ ਕੀਤਾ ਗਿਆ, ਜਦੋਂ ਕਿ ਸਾਰੇ ਪੱਧਰਾਂ 'ਤੇ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਇਆ ਗਿਆ (видео). ਅਸੀਂ ਓਲੇਗ ਦੀ ਕਹਾਣੀ ਦੇ ਲੇਖਕਾਂ ਦਾ ਧੰਨਵਾਦ ਕਰਦੇ ਹਾਂ ਸਨੀਸ ਈਫਿਮੋਵਾ ਅਤੇ ਅਲੈਗਜ਼ੈਂਡਰਾ ਡਾਇਮੋਵਾ, ਜਿਨ੍ਹਾਂ ਨੇ ਕਾਨਫਰੰਸ ਵਿਚ ਆਪਣਾ ਅਨੁਭਵ ਸਾਂਝਾ ਕੀਤਾ ਅਪਟਾਈਮ ਦਿਨ 4.

— ਆਓ ਇਸ ਬਾਰੇ ਥੋੜੀ ਜਾਣ-ਪਛਾਣ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰੀਏ ਕਿ ਅਸੀਂ ਫੋਟੋਆਂ ਨੂੰ ਕਿਵੇਂ ਸਟੋਰ ਅਤੇ ਕੈਸ਼ ਕਰਦੇ ਹਾਂ। ਸਾਡੇ ਕੋਲ ਇੱਕ ਪਰਤ ਹੈ ਜਿੱਥੇ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਇੱਕ ਲੇਅਰ ਜਿੱਥੇ ਅਸੀਂ ਫੋਟੋਆਂ ਨੂੰ ਕੈਸ਼ ਕਰਦੇ ਹਾਂ। ਇਸਦੇ ਨਾਲ ਹੀ, ਜੇਕਰ ਅਸੀਂ ਇੱਕ ਉੱਚ ਚਾਲ ਦੀ ਦਰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ ਅਤੇ ਸਟੋਰੇਜ 'ਤੇ ਲੋਡ ਨੂੰ ਘਟਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਸਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਇੱਕ ਵਿਅਕਤੀਗਤ ਉਪਭੋਗਤਾ ਦੀ ਹਰੇਕ ਫੋਟੋ ਇੱਕ ਕੈਚਿੰਗ ਸਰਵਰ 'ਤੇ ਹੋਵੇ। ਨਹੀਂ ਤਾਂ, ਸਾਨੂੰ ਓਨੀਆਂ ਗੁਣਾ ਜ਼ਿਆਦਾ ਡਿਸਕਾਂ ਇੰਸਟਾਲ ਕਰਨੀਆਂ ਪੈਣਗੀਆਂ ਜਿੰਨੀਆਂ ਸਾਡੇ ਕੋਲ ਵਧੇਰੇ ਸਰਵਰ ਹਨ। ਸਾਡੀ ਚਾਲ ਦੀ ਦਰ ਲਗਭਗ 99% ਹੈ, ਯਾਨੀ ਅਸੀਂ ਆਪਣੀ ਸਟੋਰੇਜ 'ਤੇ ਲੋਡ ਨੂੰ 100 ਗੁਣਾ ਘਟਾ ਰਹੇ ਹਾਂ, ਅਤੇ ਅਜਿਹਾ ਕਰਨ ਲਈ, 10 ਸਾਲ ਪਹਿਲਾਂ, ਜਦੋਂ ਇਹ ਸਭ ਬਣਾਇਆ ਜਾ ਰਿਹਾ ਸੀ, ਸਾਡੇ ਕੋਲ 50 ਸਰਵਰ ਸਨ। ਇਸ ਅਨੁਸਾਰ, ਇਹਨਾਂ ਫੋਟੋਆਂ ਦੀ ਸੇਵਾ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ 50 ਬਾਹਰੀ ਡੋਮੇਨਾਂ ਦੀ ਲੋੜ ਹੈ ਜੋ ਇਹ ਸਰਵਰ ਸੇਵਾ ਕਰਦੇ ਹਨ।

ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਸਵਾਲ ਤੁਰੰਤ ਉੱਠਿਆ: ਜੇਕਰ ਸਾਡੇ ਸਰਵਰ ਵਿੱਚੋਂ ਕੋਈ ਇੱਕ ਡਾਊਨ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਣਉਪਲਬਧ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਟ੍ਰੈਫਿਕ ਦਾ ਕਿਹੜਾ ਹਿੱਸਾ ਗੁਆਉਂਦੇ ਹਾਂ? ਅਸੀਂ ਮਾਰਕੀਟ 'ਤੇ ਕੀ ਸੀ ਉਸ ਨੂੰ ਦੇਖਿਆ ਅਤੇ ਹਾਰਡਵੇਅਰ ਦਾ ਇੱਕ ਟੁਕੜਾ ਖਰੀਦਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਤਾਂ ਜੋ ਇਹ ਸਾਡੀਆਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰ ਸਕੇ। ਚੋਣ F5-ਨੈੱਟਵਰਕ ਕੰਪਨੀ ਦੇ ਹੱਲ 'ਤੇ ਡਿੱਗ ਗਈ (ਜਿਸ ਨੇ, ਹਾਲ ਹੀ ਵਿੱਚ, NGINX, Inc ਖਰੀਦਿਆ ਹੈ): BIG-IP ਸਥਾਨਕ ਟ੍ਰੈਫਿਕ ਮੈਨੇਜਰ.

ਹਾਰਡਵੇਅਰ ਦਾ ਇਹ ਟੁਕੜਾ (LTM) ਕੀ ਕਰਦਾ ਹੈ: ਇਹ ਇੱਕ ਲੋਹੇ ਦਾ ਰਾਊਟਰ ਹੈ ਜੋ ਇਸਦੇ ਬਾਹਰੀ ਪੋਰਟਾਂ ਦੀ ਆਇਰਨ ਰਿਡੰਡੈਂਸੀ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਕੁਝ ਸੈਟਿੰਗਾਂ 'ਤੇ, ਨੈਟਵਰਕ ਟੌਪੋਲੋਜੀ ਦੇ ਅਧਾਰ 'ਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੂਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸਿਹਤ ਜਾਂਚਾਂ ਕਰਦਾ ਹੈ। ਇਹ ਸਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿ ਹਾਰਡਵੇਅਰ ਦੇ ਇਸ ਹਿੱਸੇ ਨੂੰ ਪ੍ਰੋਗਰਾਮ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ। ਇਸ ਅਨੁਸਾਰ, ਅਸੀਂ ਇਸ ਤਰਕ ਦਾ ਵਰਣਨ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਇੱਕ ਖਾਸ ਉਪਭੋਗਤਾ ਦੀਆਂ ਤਸਵੀਰਾਂ ਇੱਕ ਖਾਸ ਕੈਸ਼ ਤੋਂ ਕਿਵੇਂ ਦਿੱਤੀਆਂ ਗਈਆਂ ਸਨ। ਇਹ ਕਿਦੇ ਵਰਗਾ ਦਿਸਦਾ ਹੈ? ਹਾਰਡਵੇਅਰ ਦਾ ਇੱਕ ਟੁਕੜਾ ਹੈ ਜੋ ਇੱਕ ਡੋਮੇਨ, ਇੱਕ ਆਈਪੀ 'ਤੇ ਇੰਟਰਨੈਟ ਨੂੰ ਵੇਖਦਾ ਹੈ, ssl ਆਫਲੋਡ ਕਰਦਾ ਹੈ, HTTP ਬੇਨਤੀਆਂ ਨੂੰ ਪਾਰਸ ਕਰਦਾ ਹੈ, IRule ਤੋਂ ਇੱਕ ਕੈਸ਼ ਨੰਬਰ ਚੁਣਦਾ ਹੈ, ਕਿੱਥੇ ਜਾਣਾ ਹੈ, ਅਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਉੱਥੇ ਜਾਣ ਦਿੰਦਾ ਹੈ। ਇਸ ਦੇ ਨਾਲ ਹੀ, ਇਹ ਸਿਹਤ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਮਸ਼ੀਨ ਅਣਉਪਲਬਧ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ, ਉਸ ਸਮੇਂ ਅਸੀਂ ਇਸਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਬਣਾਇਆ ਸੀ ਕਿ ਟ੍ਰੈਫਿਕ ਇੱਕ ਬੈਕਅਪ ਸਰਵਰ ਵਿੱਚ ਚਲਾ ਗਿਆ. ਸੰਰਚਨਾ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਬੇਸ਼ੱਕ, ਕੁਝ ਸੂਖਮਤਾਵਾਂ ਹਨ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਕੁਝ ਬਹੁਤ ਸਧਾਰਨ ਹੈ: ਅਸੀਂ ਇੱਕ ਕਾਰਡ ਰਜਿਸਟਰ ਕਰਦੇ ਹਾਂ, ਨੈੱਟਵਰਕ 'ਤੇ ਸਾਡੇ ਆਈਪੀ ਨਾਲ ਇੱਕ ਖਾਸ ਨੰਬਰ ਦਾ ਪੱਤਰ ਵਿਹਾਰ, ਅਸੀਂ ਕਹਿੰਦੇ ਹਾਂ ਕਿ ਅਸੀਂ 80 ਪੋਰਟਾਂ 'ਤੇ ਸੁਣਾਂਗੇ. ਅਤੇ 443, ਅਸੀਂ ਕਹਿੰਦੇ ਹਾਂ ਕਿ ਜੇਕਰ ਸਰਵਰ ਅਣਉਪਲਬਧ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਬੈਕਅੱਪ ਇੱਕ 'ਤੇ ਟ੍ਰੈਫਿਕ ਭੇਜਣ ਦੀ ਲੋੜ ਹੈ, ਇਸ ਸਥਿਤੀ ਵਿੱਚ 35ਵੀਂ, ਅਤੇ ਅਸੀਂ ਇਸ ਬਾਰੇ ਤਰਕ ਦੇ ਸਮੂਹ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਾਂ ਕਿ ਇਸ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਕਿਵੇਂ ਵੱਖ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਿਰਫ ਸਮੱਸਿਆ ਇਹ ਸੀ ਕਿ ਜਿਸ ਭਾਸ਼ਾ ਵਿੱਚ ਹਾਰਡਵੇਅਰ ਪ੍ਰੋਗਰਾਮ ਕੀਤਾ ਗਿਆ ਸੀ ਉਹ Tcl ਸੀ। ਜੇ ਕਿਸੇ ਨੂੰ ਇਹ ਬਿਲਕੁਲ ਯਾਦ ਹੈ... ਇਹ ਭਾਸ਼ਾ ਪ੍ਰੋਗਰਾਮਿੰਗ ਲਈ ਸੁਵਿਧਾਜਨਕ ਭਾਸ਼ਾ ਨਾਲੋਂ ਸਿਰਫ਼ ਲਿਖਣ ਲਈ ਹੈ:

ਸਾਨੂੰ ਕੀ ਮਿਲਿਆ? ਸਾਨੂੰ ਹਾਰਡਵੇਅਰ ਦਾ ਇੱਕ ਟੁਕੜਾ ਪ੍ਰਾਪਤ ਹੋਇਆ ਹੈ ਜੋ ਸਾਡੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਉੱਚ ਉਪਲਬਧਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ, ਸਾਡੇ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੂਟ ਕਰਦਾ ਹੈ, ਸਿਹਤ ਲਾਭ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਅਤੇ ਸਹੀ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਕੰਮ ਕਰਦਾ ਹੈ: ਪਿਛਲੇ 10 ਸਾਲਾਂ ਤੋਂ ਇਸ ਬਾਰੇ ਕੋਈ ਸ਼ਿਕਾਇਤ ਨਹੀਂ ਹੋਈ ਹੈ. 2018 ਦੀ ਸ਼ੁਰੂਆਤ ਤੱਕ, ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਤੀ ਸਕਿੰਟ ਲਗਭਗ 80k ਫੋਟੋਆਂ ਭੇਜ ਰਹੇ ਸੀ। ਇਹ ਸਾਡੇ ਦੋਵਾਂ ਡਾਟਾ ਸੈਂਟਰਾਂ ਤੋਂ ਲਗਭਗ 80 ਗੀਗਾਬਾਈਟ ਟ੍ਰੈਫਿਕ ਹੈ।

ਹਾਲਾਂਕਿ…

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

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

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

ਭਾਵ, ਅਸੀਂ ਸਮੱਸਿਆ ਦੇ ਸਰੋਤ ਦੀ ਪਛਾਣ ਕੀਤੀ ਹੈ, ਰੁਕਾਵਟ ਦੀ ਪਛਾਣ ਕੀਤੀ ਹੈ. ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਬਾਕੀ ਹੈ ਕਿ ਅਸੀਂ ਕੀ ਕਰਾਂਗੇ.

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

ਕਿਉਂਕਿ ਕੰਮ "ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਕੁਝ ਕਰੋ ਅਤੇ ਸਾਡੇ ਕੋਲ ਮੌਜੂਦ ਹਾਰਡਵੇਅਰ ਦੀ ਵਰਤੋਂ ਕਰੋ" ਵਰਗਾ ਲੱਗ ਰਿਹਾ ਸੀ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਅਸੀਂ ਸੋਚਿਆ ਕਿ ਕੁਝ ਬਹੁਤ ਸ਼ਕਤੀਸ਼ਾਲੀ ਮਸ਼ੀਨਾਂ ਨੂੰ ਸਾਹਮਣੇ ਤੋਂ ਹਟਾਓ, Nginx ਨੂੰ ਉੱਥੇ ਰੱਖੋ, ਜਿਸ ਨਾਲ ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਕਿਵੇਂ ਕਰਨਾ ਹੈ ਕੰਮ ਕਰੋ ਅਤੇ ਉਹੀ ਤਰਕ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਜੋ ਹਾਰਡਵੇਅਰ ਕਰਦਾ ਸੀ। ਭਾਵ, ਅਸਲ ਵਿੱਚ, ਅਸੀਂ ਆਪਣਾ ਹਾਰਡਵੇਅਰ ਛੱਡ ਦਿੱਤਾ, 4 ਹੋਰ ਸਰਵਰ ਸਥਾਪਤ ਕੀਤੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸਾਨੂੰ ਸੰਰਚਿਤ ਕਰਨਾ ਸੀ, ਉਹਨਾਂ ਲਈ ਬਾਹਰੀ ਡੋਮੇਨ ਬਣਾਏ, ਜਿਵੇਂ ਕਿ ਇਹ 10 ਸਾਲ ਪਹਿਲਾਂ ਸੀ... ਜੇਕਰ ਇਹ ਮਸ਼ੀਨਾਂ ਡਿੱਗ ਗਈਆਂ ਤਾਂ ਅਸੀਂ ਉਪਲਬਧਤਾ ਵਿੱਚ ਥੋੜਾ ਜਿਹਾ ਗੁਆ ਦਿੱਤਾ, ਪਰ ਅਜੇ ਵੀ ਘੱਟ, ਉਹਨਾਂ ਨੇ ਸਾਡੇ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਹੱਲ ਕੀਤਾ।

ਇਸ ਅਨੁਸਾਰ, ਤਰਕ ਉਹੀ ਰਹਿੰਦਾ ਹੈ: ਅਸੀਂ Nginx ਨੂੰ ਸਥਾਪਿਤ ਕਰਦੇ ਹਾਂ, ਇਹ SSL-offload ਕਰ ਸਕਦਾ ਹੈ, ਅਸੀਂ ਕਿਸੇ ਤਰ੍ਹਾਂ ਰੂਟਿੰਗ ਤਰਕ ਨੂੰ ਪ੍ਰੋਗਰਾਮ ਕਰ ਸਕਦੇ ਹਾਂ, ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ ਸਿਹਤ-ਜਾਂਚ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਸਿਰਫ਼ ਉਸ ਤਰਕ ਨੂੰ ਡੁਪਲੀਕੇਟ ਕਰ ਸਕਦੇ ਹਾਂ ਜੋ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਸੀ।

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

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

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

ਇਸ ਤੋਂ ਬਚਣ ਲਈ, ਅਸੀਂ ਦੋ ਚੀਜ਼ਾਂ ਕੀਤੀਆਂ:

a) ਉਹਨਾਂ ਨੇ Nginx ਨੂੰ ਇਸ ਨੂੰ ਹੱਥੀਂ ਕਰਨ ਤੋਂ ਮਨ੍ਹਾ ਕੀਤਾ - ਅਤੇ ਬਦਕਿਸਮਤੀ ਨਾਲ, ਅਜਿਹਾ ਕਰਨ ਦਾ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ ਹੈ ਸਿਰਫ਼ ਅਧਿਕਤਮ ਫੇਲ ਸੈਟਿੰਗਾਂ ਨੂੰ ਸੈੱਟ ਕਰਨਾ।

b) ਸਾਨੂੰ ਯਾਦ ਹੈ ਕਿ ਦੂਜੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਅਸੀਂ ਇੱਕ ਮਾਡਿਊਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਜੋ ਸਾਨੂੰ ਪਿਛੋਕੜ ਦੀ ਸਿਹਤ ਜਾਂਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ - ਇਸਦੇ ਅਨੁਸਾਰ, ਅਸੀਂ ਅਕਸਰ ਸਿਹਤ ਜਾਂਚਾਂ ਕੀਤੀਆਂ ਤਾਂ ਜੋ ਦੁਰਘਟਨਾ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਡਾਊਨਟਾਈਮ ਘੱਟ ਹੋਵੇ।

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

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

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

ਅਤੇ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਚਾਰ ਸਰਵਰਾਂ ਨੂੰ ਜੋੜ ਕੇ, ਇਹ ਸਾਨੂੰ ਮਿਲਿਆ ਹੈ: ਅਸੀਂ ਲੋਡ ਦੇ ਹਿੱਸੇ ਨੂੰ ਬਦਲ ਦਿੱਤਾ - ਅਸੀਂ ਇਸਨੂੰ LTM ਤੋਂ ਇਹਨਾਂ ਸਰਵਰਾਂ ਲਈ ਹਟਾ ਦਿੱਤਾ, ਉੱਥੇ ਉਹੀ ਤਰਕ ਲਾਗੂ ਕੀਤਾ, ਮਿਆਰੀ ਹਾਰਡਵੇਅਰ ਅਤੇ ਸੌਫਟਵੇਅਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਤੇ ਤੁਰੰਤ ਬੋਨਸ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜੋ ਇਹ ਸਰਵਰ ਕਰ ਸਕਦੇ ਹਨ. ਸਕੇਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੂੰ ਲੋੜ ਅਨੁਸਾਰ ਹੀ ਸਪਲਾਈ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਖੈਰ, ਸਿਰਫ ਨਕਾਰਾਤਮਕ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਬਾਹਰੀ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਉੱਚ ਉਪਲਬਧਤਾ ਨੂੰ ਗੁਆ ਦਿੱਤਾ ਹੈ. ਪਰ ਉਸ ਸਮੇਂ ਸਾਨੂੰ ਇਹ ਕੁਰਬਾਨੀ ਕਰਨੀ ਪਈ, ਕਿਉਂਕਿ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਤੁਰੰਤ ਹੱਲ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ। ਇਸ ਲਈ, ਅਸੀਂ ਲੋਡ ਦਾ ਕੁਝ ਹਿੱਸਾ ਹਟਾ ਦਿੱਤਾ, ਇਹ ਉਸ ਸਮੇਂ ਲਗਭਗ 40% ਸੀ, LTM ਨੇ ਚੰਗਾ ਮਹਿਸੂਸ ਕੀਤਾ, ਅਤੇ ਅਸਲ ਵਿੱਚ ਸਮੱਸਿਆ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਦੋ ਹਫ਼ਤਿਆਂ ਬਾਅਦ, ਅਸੀਂ ਪ੍ਰਤੀ ਸਕਿੰਟ 45k ਬੇਨਤੀਆਂ ਨਹੀਂ ਭੇਜਣੀਆਂ ਸ਼ੁਰੂ ਕੀਤੀਆਂ, ਪਰ 55k. ਵਾਸਤਵ ਵਿੱਚ, ਅਸੀਂ 20% ਤੱਕ ਵਧਿਆ - ਇਹ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਉਹ ਟ੍ਰੈਫਿਕ ਹੈ ਜੋ ਅਸੀਂ ਉਪਭੋਗਤਾ ਨੂੰ ਨਹੀਂ ਦਿੱਤਾ. ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਉਹਨਾਂ ਨੇ ਇਸ ਬਾਰੇ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਕਿ ਬਾਕੀ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕਰਨਾ ਹੈ - ਉੱਚ ਬਾਹਰੀ ਪਹੁੰਚਯੋਗਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ.

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

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

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

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

ਇਸ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਬਾਹਰੀ IP ਐਡਰੈੱਸ ਦੀ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਇਆ ਹੈ। ਅਗਲਾ ਹਿੱਸਾ ਕਿਸੇ ਤਰ੍ਹਾਂ ਬਾਹਰੀ IP ਐਡਰੈੱਸ ਤੋਂ ਫੋਟੋ ਰਾਊਟਰਾਂ ਤੱਕ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਇਸਨੂੰ ਖਤਮ ਕਰ ਰਹੇ ਹਨ। ਸੰਤੁਲਨ ਪ੍ਰੋਟੋਕੋਲ ਨਾਲ ਸਭ ਕੁਝ ਬਿਲਕੁਲ ਸਪੱਸ਼ਟ ਹੈ. ਇਹ ਜਾਂ ਤਾਂ ਇੱਕ ਸਧਾਰਨ ਰਾਉਂਡ-ਰੋਬਿਨ ਹੈ, ਜਾਂ ਥੋੜ੍ਹਾ ਹੋਰ ਗੁੰਝਲਦਾਰ ਚੀਜ਼ਾਂ, ਡਬਲਯੂਆਰਆਰ, ਸੂਚੀ ਕੁਨੈਕਸ਼ਨ ਅਤੇ ਹੋਰ। ਇਹ ਅਸਲ ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ, ਇੱਥੇ ਕੁਝ ਖਾਸ ਨਹੀਂ ਹੈ. ਪਰ ਡਿਲੀਵਰੀ ਵਿਧੀ... ਇੱਥੇ ਅਸੀਂ ਇਸ ਗੱਲ 'ਤੇ ਡੂੰਘਾਈ ਨਾਲ ਵਿਚਾਰ ਕਰਾਂਗੇ ਕਿ ਅਸੀਂ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਕਿਉਂ ਚੁਣਿਆ ਹੈ। ਇਹ NAT, ਡਾਇਰੈਕਟ ਰੂਟਿੰਗ ਅਤੇ TUN ਹਨ। ਤੱਥ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਤੁਰੰਤ ਸਾਈਟਾਂ ਤੋਂ 100 ਗੀਗਾਬਾਈਟ ਟ੍ਰੈਫਿਕ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਹੈ. ਜੇ ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਲਗਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ 10 ਗੀਗਾਬਿਟ ਕਾਰਡਾਂ ਦੀ ਲੋੜ ਹੈ, ਠੀਕ ਹੈ? ਇੱਕ ਸਰਵਰ ਵਿੱਚ 10 ਗੀਗਾਬਿਟ ਕਾਰਡ ਪਹਿਲਾਂ ਹੀ ਸਾਡੇ "ਸਟੈਂਡਰਡ ਉਪਕਰਣ" ਦੇ ਸੰਕਲਪ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹਨ। ਅਤੇ ਫਿਰ ਸਾਨੂੰ ਯਾਦ ਆਇਆ ਕਿ ਅਸੀਂ ਸਿਰਫ ਕੁਝ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਦਿੰਦੇ, ਅਸੀਂ ਫੋਟੋਆਂ ਦਿੰਦੇ ਹਾਂ.

ਕੀ ਖਾਸ ਹੈ? - ਆਉਣ ਵਾਲੇ ਅਤੇ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਬਹੁਤ ਅੰਤਰ। ਆਉਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਬਹੁਤ ਛੋਟਾ ਹੈ, ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਬਹੁਤ ਵੱਡਾ ਹੈ:

ਜੇ ਤੁਸੀਂ ਇਹਨਾਂ ਗ੍ਰਾਫਾਂ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਇਸ ਸਮੇਂ ਨਿਰਦੇਸ਼ਕ ਲਗਭਗ 200 ਐਮਬੀ ਪ੍ਰਤੀ ਸਕਿੰਟ ਪ੍ਰਾਪਤ ਕਰ ਰਿਹਾ ਹੈ, ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਆਮ ਦਿਨ ਹੈ. ਅਸੀਂ 4,500 MB ਪ੍ਰਤੀ ਸਕਿੰਟ ਵਾਪਸ ਦਿੰਦੇ ਹਾਂ, ਸਾਡਾ ਅਨੁਪਾਤ ਲਗਭਗ 1/22 ਹੈ। ਇਹ ਪਹਿਲਾਂ ਹੀ ਸਪੱਸ਼ਟ ਹੈ ਕਿ 22 ਵਰਕਰ ਸਰਵਰਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਊਟਗੋਇੰਗ ਟ੍ਰੈਫਿਕ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਸਿਰਫ ਇੱਕ ਦੀ ਲੋੜ ਹੈ ਜੋ ਇਸ ਕਨੈਕਸ਼ਨ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸਿੱਧਾ ਰੂਟਿੰਗ ਐਲਗੋਰਿਦਮ ਸਾਡੀ ਸਹਾਇਤਾ ਲਈ ਆਉਂਦਾ ਹੈ।

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

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

ਅਸੀਂ ਮੱਧ ਵਿੱਚ ਕਿਤੇ ਰੁਕ ਗਏ: ਸਾਡੇ ਕੋਲ ਇੱਕ ਖਾਸ ਸਥਾਨ ਲਈ ਇੱਕ https ਬੇਨਤੀ ਹੈ, ਸਕ੍ਰਿਪਟ ਨੂੰ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਜੇਕਰ ਇਹ 200ਵੇਂ ਜਵਾਬ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਵਿਸ਼ਵਾਸ ਕਰਦੇ ਹਾਂ ਕਿ ਇਸ ਸਰਵਰ ਨਾਲ ਸਭ ਕੁਝ ਠੀਕ ਹੈ, ਕਿ ਇਹ ਜ਼ਿੰਦਾ ਹੈ ਅਤੇ ਕਾਫ਼ੀ ਚਾਲੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ. ਆਸਾਨੀ ਨਾਲ.

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

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

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

ਇਹ ਕਹਿਣਾ ਬਾਕੀ ਹੈ ਕਿ ਇਸ ਸਭ 'ਤੇ, ਬੇਸ਼ਕ, ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ Keepalivede, ਜਿਵੇਂ ਕਿ ਬਹੁਤ ਸਮਾਂ ਪਹਿਲਾਂ ਲਿਖਿਆ ਗਿਆ ਸੌਫਟਵੇਅਰ, ਕੋਲ ਇਸਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੇ ਕਈ ਤਰੀਕੇ ਹਨ, ਦੋਵੇਂ DBus, SMTP, SNMP, ਅਤੇ ਸਟੈਂਡਰਡ ਜ਼ੈਬਿਕਸ ਦੁਆਰਾ ਜਾਂਚਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਉਹ ਖੁਦ ਜਾਣਦਾ ਹੈ ਕਿ ਲਗਭਗ ਹਰ ਛਿੱਕ ਲਈ ਅੱਖਰ ਕਿਵੇਂ ਲਿਖਣੇ ਹਨ, ਅਤੇ ਇਮਾਨਦਾਰ ਹੋਣ ਲਈ, ਕਿਸੇ ਸਮੇਂ ਅਸੀਂ ਇਸਨੂੰ ਬੰਦ ਕਰਨ ਬਾਰੇ ਵੀ ਸੋਚਿਆ, ਕਿਉਂਕਿ ਉਹ ਕਿਸੇ ਵੀ ਟ੍ਰੈਫਿਕ ਸਵਿਚਿੰਗ, ਸਵਿਚਿੰਗ, ਹਰ IP ਕਨੈਕਸ਼ਨ ਲਈ ਬਹੁਤ ਸਾਰੇ ਪੱਤਰ ਲਿਖਦਾ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹੋਰ. ਬੇਸ਼ੱਕ, ਜੇ ਬਹੁਤ ਸਾਰੇ ਸਰਵਰ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਇਹਨਾਂ ਅੱਖਰਾਂ ਨਾਲ ਆਪਣੇ ਆਪ ਨੂੰ ਹਾਵੀ ਕਰ ਸਕਦੇ ਹੋ. ਅਸੀਂ ਸਟੈਂਡਰਡ ਤਰੀਕਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਫੋਟੋ ਰਾਊਟਰਾਂ 'ਤੇ nginx ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਹਾਰਡਵੇਅਰ ਨਿਗਰਾਨੀ ਦੂਰ ਨਹੀਂ ਹੋਈ ਹੈ। ਅਸੀਂ, ਬੇਸ਼ਕ, ਦੋ ਹੋਰ ਚੀਜ਼ਾਂ ਦੀ ਸਲਾਹ ਦੇਵਾਂਗੇ: ਪਹਿਲੀ, ਬਾਹਰੀ ਸਿਹਤ-ਜਾਂਚ ਅਤੇ ਉਪਲਬਧਤਾ, ਕਿਉਂਕਿ ਭਾਵੇਂ ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਸਲ ਵਿੱਚ, ਸ਼ਾਇਦ ਉਪਭੋਗਤਾ ਬਾਹਰੀ ਪ੍ਰਦਾਤਾਵਾਂ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਜਾਂ ਕਿਸੇ ਹੋਰ ਗੁੰਝਲਦਾਰ ਚੀਜ਼ ਕਾਰਨ ਫੋਟੋਆਂ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰਦੇ। ਕਿਸੇ ਹੋਰ ਨੈੱਟਵਰਕ 'ਤੇ, ਐਮਾਜ਼ਾਨ ਜਾਂ ਕਿਸੇ ਹੋਰ ਥਾਂ 'ਤੇ, ਇੱਕ ਵੱਖਰੀ ਮਸ਼ੀਨ ਜੋ ਤੁਹਾਡੇ ਸਰਵਰਾਂ ਨੂੰ ਬਾਹਰੋਂ ਪਿੰਗ ਕਰ ਸਕਦੀ ਹੈ, ਇਹ ਹਮੇਸ਼ਾ ਰੱਖਣ ਯੋਗ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਹ ਉਹਨਾਂ ਲਈ, ਜੋ ਜਾਣਦੇ ਹਨ ਕਿ ਮੁਸ਼ਕਲ ਮਸ਼ੀਨ ਸਿਖਲਾਈ, ਜਾਂ ਸਧਾਰਨ ਨਿਗਰਾਨੀ ਕਿਵੇਂ ਕਰਨੀ ਹੈ, ਜਾਂ ਤਾਂ ਵਿਗਾੜ ਖੋਜ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਯੋਗ ਹੈ। , ਘੱਟੋ-ਘੱਟ ਇਹ ਪਤਾ ਲਗਾਉਣ ਲਈ ਕਿ ਕੀ ਬੇਨਤੀਆਂ ਤੇਜ਼ੀ ਨਾਲ ਘਟੀਆਂ ਹਨ, ਜਾਂ, ਇਸਦੇ ਉਲਟ, ਵਧੀਆਂ ਹਨ। ਇਹ ਲਾਭਦਾਇਕ ਵੀ ਹੋ ਸਕਦਾ ਹੈ।

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

ਅਸੀਂ ਅੰਤ ਵਿੱਚ ਕੀ ਕੀਤਾ? 2018 ਦੀਆਂ ਜਨਵਰੀ ਦੀਆਂ ਛੁੱਟੀਆਂ ਦੌਰਾਨ ਸਾਨੂੰ ਸਮੱਸਿਆ ਆਈ ਸੀ। ਪਹਿਲੇ ਛੇ ਮਹੀਨਿਆਂ ਵਿੱਚ ਜਦੋਂ ਅਸੀਂ ਇਸ ਸਕੀਮ ਨੂੰ ਲਾਗੂ ਕੀਤਾ, ਅਸੀਂ LTM ਤੋਂ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਹਟਾਉਣ ਲਈ ਇਸਨੂੰ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਫੈਲਾਇਆ, ਅਸੀਂ ਸਿਰਫ ਇੱਕ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ 40 ਗੀਗਾਬਾਈਟ ਤੋਂ 60 ਗੀਗਾਬਾਈਟ ਤੱਕ ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਵਾਧਾ ਕੀਤਾ, ਅਤੇ ਉਸੇ ਸਮੇਂ ਲਈ ਪੂਰਾ 2018 ਸਾਲ ਪ੍ਰਤੀ ਸਕਿੰਟ ਲਗਭਗ ਤਿੰਨ ਗੁਣਾ ਜ਼ਿਆਦਾ ਫੋਟੋਆਂ ਭੇਜਣ ਦੇ ਯੋਗ ਸੀ।

ਸਰੋਤ: www.habr.com