ਇੱਕ-ਕਲਾਊਡ - Odnoklassniki ਵਿੱਚ ਡਾਟਾ ਸੈਂਟਰ ਪੱਧਰ ਦਾ OS

ਅਲੋਹਾ, ਲੋਕੋ! ਮੇਰਾ ਨਾਮ ਓਲੇਗ ਅਨਾਸਤਾਸੇਵ ਹੈ, ਮੈਂ ਪਲੇਟਫਾਰਮ ਟੀਮ ਵਿੱਚ ਓਡਨੋਕਲਾਸਨੀਕੀ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹਾਂ। ਅਤੇ ਮੇਰੇ ਤੋਂ ਇਲਾਵਾ, ਓਡਨੋਕਲਾਸਨੀਕੀ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਹਾਰਡਵੇਅਰ ਕੰਮ ਕਰ ਰਹੇ ਹਨ. ਸਾਡੇ ਕੋਲ 500 ਹਜ਼ਾਰ ਤੋਂ ਵੱਧ ਸਰਵਰਾਂ ਦੇ ਨਾਲ ਲਗਭਗ 8 ਰੈਕ ਵਾਲੇ ਚਾਰ ਡਾਟਾ ਸੈਂਟਰ ਹਨ। ਇੱਕ ਖਾਸ ਬਿੰਦੂ 'ਤੇ, ਅਸੀਂ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਇੱਕ ਨਵੀਂ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀ ਦੀ ਸ਼ੁਰੂਆਤ ਸਾਨੂੰ ਸਾਜ਼ੋ-ਸਾਮਾਨ ਨੂੰ ਵਧੇਰੇ ਕੁਸ਼ਲਤਾ ਨਾਲ ਲੋਡ ਕਰਨ, ਪਹੁੰਚ ਪ੍ਰਬੰਧਨ ਦੀ ਸਹੂਲਤ, ਕੰਪਿਊਟਿੰਗ ਸਰੋਤਾਂ ਦੀ (ਮੁੜ) ਵੰਡ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨ, ਨਵੀਆਂ ਸੇਵਾਵਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਨੂੰ ਤੇਜ਼ ਕਰਨ, ਅਤੇ ਜਵਾਬਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗੀ। ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਹਾਦਸਿਆਂ ਲਈ.

ਇਸ ਦਾ ਕੀ ਨਿਕਲਿਆ?

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

ਮੁੱਖ ਪੋਰਟਲ ਦੇ ਦੋਵੇਂ ਮੋਰਚਿਆਂ 'ਤੇ ਉਪਭੋਗਤਾ ਬੇਨਤੀਆਂ ਪ੍ਰਾਪਤ ਹੁੰਦੀਆਂ ਹਨ www.ok.ru, ਅਤੇ ਹੋਰਾਂ 'ਤੇ, ਉਦਾਹਰਨ ਲਈ ਸੰਗੀਤ API ਮੋਰਚਿਆਂ 'ਤੇ। ਕਾਰੋਬਾਰੀ ਤਰਕ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਲਈ, ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ, ਜੋ ਕਿ ਬੇਨਤੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਸਮੇਂ, ਲੋੜੀਂਦੀਆਂ ਵਿਸ਼ੇਸ਼ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ - ਇੱਕ-ਗ੍ਰਾਫ (ਸਮਾਜਿਕ ਕਨੈਕਸ਼ਨਾਂ ਦਾ ਗ੍ਰਾਫ), ਉਪਭੋਗਤਾ-ਕੈਸ਼ (ਉਪਭੋਗਤਾ ਪ੍ਰੋਫਾਈਲਾਂ ਦਾ ਕੈਸ਼), ਆਦਿ।

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

ਅਜਿਹਾ ਕਿਉਂ ਹੈ? ਇਸ ਪਹੁੰਚ ਦੇ ਕਈ ਫਾਇਦੇ ਸਨ:

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

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

ਇਸ ਪਹੁੰਚ ਨੇ ਸਾਨੂੰ ਵੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਵਿਸ਼ੇਸ਼ ਲੋਹੇ ਦੀ ਸੰਰਚਨਾ ਇਸ ਸਰਵਰ 'ਤੇ ਚੱਲ ਰਹੇ ਕੰਮ ਲਈ। ਜੇਕਰ ਟਾਸਕ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡਾਟਾ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ 4 ਡਿਸਕਾਂ ਦੇ ਨਾਲ ਇੱਕ ਚੈਸੀ ਦੇ ਨਾਲ ਇੱਕ 38U ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਜੇਕਰ ਕੰਮ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕੰਪਿਊਟੇਸ਼ਨਲ ਹੈ, ਤਾਂ ਅਸੀਂ ਇੱਕ ਸਸਤਾ 1U ਸਰਵਰ ਖਰੀਦ ਸਕਦੇ ਹਾਂ। ਇਹ ਗਣਨਾਤਮਕ ਤੌਰ 'ਤੇ ਕੁਸ਼ਲ ਹੈ। ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ, ਇਹ ਪਹੁੰਚ ਸਾਨੂੰ ਇੱਕ ਦੋਸਤਾਨਾ ਸੋਸ਼ਲ ਨੈਟਵਰਕ ਦੇ ਮੁਕਾਬਲੇ ਚਾਰ ਗੁਣਾ ਘੱਟ ਮਸ਼ੀਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ।

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

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

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

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

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

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

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

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

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

ਜਦੋਂ ਤੁਹਾਡੇ ਕੋਲ 8 ਹਜ਼ਾਰ ਸਰਵਰ ਅਤੇ 8-16 ਹਜ਼ਾਰ ਕੰਟੇਨਰ ਹੋਣ ਤਾਂ ਕੰਟੇਨਰਾਂ ਨੂੰ ਹੱਥੀਂ ਵੰਡਣਾ ਕੋਈ ਵਿਕਲਪ ਨਹੀਂ ਹੈ।

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

ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਸਾਨੂੰ ਇੱਕ ਨਿਯੰਤਰਣ ਪਰਤ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਜੋ ਇਹ ਆਪਣੇ ਆਪ ਹੀ ਕਰੇਗੀ.

ਇਸ ਲਈ ਅਸੀਂ ਇੱਕ ਸਧਾਰਨ ਅਤੇ ਸਮਝਣ ਯੋਗ ਤਸਵੀਰ 'ਤੇ ਆਏ ਜੋ ਸਾਰੇ ਆਰਕੀਟੈਕਟ ਪਸੰਦ ਕਰਦੇ ਹਨ: ਤਿੰਨ ਵਰਗ।

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

ਸਰੋਤ ਵੰਡ

ਹੁਣ ਆਉ ਬਹੁਤ ਸਾਰੇ ਮਿਨੀਅਨਾਂ ਲਈ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਸਰੋਤ ਵੰਡ ਦੀ ਸਮੱਸਿਆ ਵੱਲ ਧਿਆਨ ਦੇਈਏ।

ਇੱਕ-ਕਲਾਊਡ ਵਿੱਚ ਇੱਕ ਕੰਪਿਊਟਿੰਗ ਸਰੋਤ ਹੈ:

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

ਫਿਰ ਕੁਝ ਸੇਵਾ ਲਈ, ਉਦਾਹਰਨ ਲਈ ਉਪਭੋਗਤਾ-ਕੈਸ਼ ਲਈ, ਅਸੀਂ ਖਪਤ ਕੀਤੇ ਸਰੋਤਾਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਰਿਕਾਰਡ ਕਰ ਸਕਦੇ ਹਾਂ: 400 ਪ੍ਰੋਸੈਸਰ ਕੋਰ, 2,5 TB ਮੈਮੋਰੀ, ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ 50 Gbit/s ਟ੍ਰੈਫਿਕ, 6 ਸਪਿੰਡਲਾਂ 'ਤੇ ਸਥਿਤ HDD ਸਪੇਸ ਦਾ 100 TB। ਜਾਂ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਹੋਰ ਜਾਣੇ-ਪਛਾਣੇ ਰੂਪ ਵਿੱਚ:

alloc:
    cpu: 400
    mem: 2500
    lan_in: 50g
    lan_out: 50g
    hdd:100x6T

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

ਆਉ ਕੰਪੋਨੈਂਟਸ ਦੇ ਪਰਸਪਰ ਕ੍ਰਿਆ ਦੇ ਸਾਡੇ ਬਹੁਤ ਹੀ ਸਰਲ ਬਣਾਏ ਗਏ ਡਾਇਗ੍ਰਾਮ ਤੇ ਵਾਪਸ ਆਓ ਅਤੇ ਇਸਨੂੰ ਹੋਰ ਵੇਰਵਿਆਂ ਦੇ ਨਾਲ ਦੁਬਾਰਾ ਖਿੱਚੀਏ - ਜਿਵੇਂ ਕਿ:

ਕੀ ਤੁਹਾਡੀ ਅੱਖ ਨੂੰ ਫੜਦਾ ਹੈ:

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

ਆਓ ਤਸਵੀਰ ਨੂੰ ਦੁਬਾਰਾ ਖਿੱਚੀਏ:

ਬਾਹ! ਹਾਂ, ਅਸੀਂ ਇੱਕ ਲੜੀ ਵੇਖਦੇ ਹਾਂ! ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਸਰੋਤਾਂ ਨੂੰ ਵੱਡੇ ਭਾਗਾਂ ਵਿੱਚ ਵੰਡ ਸਕਦੇ ਹੋ: ਕਾਰਜਸ਼ੀਲ ਉਪ-ਸਿਸਟਮ (ਜਿਵੇਂ ਕਿ ਤਸਵੀਰ ਵਿੱਚ "ਸੰਗੀਤ") ਨਾਲ ਸੰਬੰਧਿਤ ਇਸ ਲੜੀ ਦੇ ਇੱਕ ਨੋਡ ਲਈ ਇੱਕ ਜ਼ਿੰਮੇਵਾਰ ਡਿਵੈਲਪਰ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰੋ, ਅਤੇ ਲੜੀ ਦੇ ਉਸੇ ਪੱਧਰ ਲਈ ਇੱਕ ਕੋਟਾ ਜੋੜੋ। ਇਹ ਦਰਜਾਬੰਦੀ ਸਾਨੂੰ ਪ੍ਰਬੰਧਨ ਦੀ ਸੌਖ ਲਈ ਸੇਵਾਵਾਂ ਨੂੰ ਵਧੇਰੇ ਲਚਕਦਾਰ ਢੰਗ ਨਾਲ ਸੰਗਠਿਤ ਕਰਨ ਦੀ ਵੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਸਾਰੇ ਵੈੱਬ ਨੂੰ ਵੰਡਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਇਹ ਸਰਵਰਾਂ ਦਾ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਸਮੂਹ ਹੈ, ਕਈ ਛੋਟੇ ਸਮੂਹਾਂ ਵਿੱਚ, ਤਸਵੀਰ ਵਿੱਚ ਗਰੁੱਪ 1, ਗਰੁੱਪ 2 ਦੇ ਰੂਪ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ।

ਵਾਧੂ ਲਾਈਨਾਂ ਨੂੰ ਹਟਾ ਕੇ, ਅਸੀਂ ਆਪਣੀ ਤਸਵੀਰ ਦੇ ਹਰੇਕ ਨੋਡ ਨੂੰ ਚਾਪਲੂਸ ਰੂਪ ਵਿੱਚ ਲਿਖ ਸਕਦੇ ਹਾਂ: group1.web.front, api.music.front, user-cache.cache.

ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ "ਹਾਇਰਾਰਕੀਕਲ ਕਤਾਰ" ਦੀ ਧਾਰਨਾ 'ਤੇ ਆਉਂਦੇ ਹਾਂ। ਇਸਦਾ ਇੱਕ ਨਾਮ ਹੈ "group1.web.front"। ਸਰੋਤਾਂ ਅਤੇ ਉਪਭੋਗਤਾ ਅਧਿਕਾਰਾਂ ਲਈ ਇੱਕ ਕੋਟਾ ਇਸ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਅਸੀਂ DevOps ਤੋਂ ਵਿਅਕਤੀ ਨੂੰ ਕਤਾਰ ਵਿੱਚ ਸੇਵਾ ਭੇਜਣ ਦੇ ਅਧਿਕਾਰ ਦੇਵਾਂਗੇ, ਅਤੇ ਅਜਿਹਾ ਕਰਮਚਾਰੀ ਕਤਾਰ ਵਿੱਚ ਕੁਝ ਲਾਂਚ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ OpsDev ਦੇ ਵਿਅਕਤੀ ਕੋਲ ਪ੍ਰਬੰਧਕੀ ਅਧਿਕਾਰ ਹੋਣਗੇ, ਅਤੇ ਹੁਣ ਉਹ ਕਤਾਰ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰ ਸਕਦਾ ਹੈ, ਉੱਥੇ ਲੋਕਾਂ ਨੂੰ ਨਿਯੁਕਤ ਕਰ ਸਕਦਾ ਹੈ, ਇਨ੍ਹਾਂ ਲੋਕਾਂ ਨੂੰ ਅਧਿਕਾਰ ਦਿਓ ਆਦਿ। ਇਸ ਕਤਾਰ 'ਤੇ ਚੱਲਣ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ ਕਤਾਰ ਦੇ ਕੋਟੇ ਦੇ ਅੰਦਰ ਚੱਲਣਗੀਆਂ। ਜੇਕਰ ਕਤਾਰ ਦਾ ਕੰਪਿਊਟਿੰਗ ਕੋਟਾ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਇੱਕੋ ਵਾਰ ਚਲਾਉਣ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਕ੍ਰਮਵਾਰ ਚਲਾਇਆ ਜਾਵੇਗਾ, ਇਸ ਤਰ੍ਹਾਂ ਕਤਾਰ ਆਪਣੇ ਆਪ ਬਣ ਜਾਵੇਗੀ।

ਆਓ ਸੇਵਾਵਾਂ 'ਤੇ ਡੂੰਘਾਈ ਨਾਲ ਵਿਚਾਰ ਕਰੀਏ। ਇੱਕ ਸੇਵਾ ਦਾ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ ਨਾਮ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਹਮੇਸ਼ਾ ਕਤਾਰ ਦਾ ਨਾਮ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। ਫਿਰ ਸਾਹਮਣੇ ਵੈੱਬ ਸੇਵਾ ਦਾ ਨਾਮ ਹੋਵੇਗਾ ok-web.group1.web.front. ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਸੇਵਾ ਜਿਸ ਨੂੰ ਇਹ ਐਕਸੈਸ ਕਰਦਾ ਹੈ ਉਸਨੂੰ ਬੁਲਾਇਆ ਜਾਵੇਗਾ ok-app.group1.web.front. ਹਰੇਕ ਸੇਵਾ ਦਾ ਇੱਕ ਮੈਨੀਫੈਸਟ ਹੁੰਦਾ ਹੈ, ਜੋ ਖਾਸ ਮਸ਼ੀਨਾਂ 'ਤੇ ਪਲੇਸਮੈਂਟ ਲਈ ਸਾਰੀ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਦਾ ਹੈ: ਇਹ ਕੰਮ ਕਿੰਨੇ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਕਰਦਾ ਹੈ, ਇਸਦੇ ਲਈ ਕਿਹੜੀ ਸੰਰਚਨਾ ਦੀ ਲੋੜ ਹੈ, ਕਿੰਨੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਇਸ ਸੇਵਾ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ। ਅਤੇ ਸੇਵਾ ਨੂੰ ਮਸ਼ੀਨਾਂ 'ਤੇ ਸਿੱਧਾ ਰੱਖਣ ਤੋਂ ਬਾਅਦ, ਇਸ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਅਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਵੀ ਨਾਮ ਦਿੱਤਾ ਗਿਆ ਹੈ - ਉਦਾਹਰਣ ਨੰਬਰ ਅਤੇ ਸੇਵਾ ਦੇ ਨਾਮ ਵਜੋਂ: 1.ok-web.group1.web.front, 2.ok-web.group1.web.front, …

ਇਹ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਹੈ: ਚੱਲ ਰਹੇ ਕੰਟੇਨਰ ਦੇ ਨਾਮ ਨੂੰ ਦੇਖ ਕੇ, ਅਸੀਂ ਤੁਰੰਤ ਬਹੁਤ ਕੁਝ ਲੱਭ ਸਕਦੇ ਹਾਂ.

ਹੁਣ ਆਓ ਇਸ ਗੱਲ 'ਤੇ ਡੂੰਘਾਈ ਨਾਲ ਵਿਚਾਰ ਕਰੀਏ ਕਿ ਇਹ ਉਦਾਹਰਣਾਂ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦੀਆਂ ਹਨ: ਕਾਰਜ।

ਟਾਸਕ ਆਈਸੋਲੇਸ਼ਨ ਕਲਾਸਾਂ

ਓਕੇ (ਅਤੇ, ਸ਼ਾਇਦ, ਹਰ ਥਾਂ) ਵਿੱਚ ਸਾਰੇ ਕਾਰਜਾਂ ਨੂੰ ਸਮੂਹਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ:

• ਸ਼ਾਰਟ ਲੇਟੈਂਸੀ ਟਾਸਕ - prod. ਅਜਿਹੇ ਕੰਮਾਂ ਅਤੇ ਸੇਵਾਵਾਂ ਲਈ, ਜਵਾਬ ਦੇਰੀ (ਲੇਟੈਂਸੀ) ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਸਿਸਟਮ ਦੁਆਰਾ ਹਰੇਕ ਬੇਨਤੀ 'ਤੇ ਕਿੰਨੀ ਜਲਦੀ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾਵੇਗੀ। ਕਾਰਜਾਂ ਦੀਆਂ ਉਦਾਹਰਨਾਂ: ਵੈੱਬ ਫਰੰਟ, ਕੈਚ, ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ, OLTP ਸਟੋਰੇਜ, ਆਦਿ।
• ਗਣਨਾ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ - ਬੈਚ. ਇੱਥੇ, ਹਰੇਕ ਖਾਸ ਬੇਨਤੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਗਤੀ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ. ਉਹਨਾਂ ਲਈ, ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਇਹ ਕਾਰਜ ਇੱਕ ਨਿਸ਼ਚਿਤ (ਲੰਬੇ) ਸਮੇਂ (ਥਰੂਪੁੱਟ) ਵਿੱਚ ਕਿੰਨੀਆਂ ਗਣਨਾਵਾਂ ਕਰੇਗਾ। ਇਹ MapReduce, Hadoop, ਮਸ਼ੀਨ ਸਿਖਲਾਈ, ਅੰਕੜੇ ਦੇ ਕੋਈ ਵੀ ਕੰਮ ਹੋਣਗੇ।
• ਬੈਕਗ੍ਰਾਊਂਡ ਕਾਰਜ - ਵਿਹਲੇ. ਅਜਿਹੇ ਕੰਮਾਂ ਲਈ, ਨਾ ਤਾਂ ਲੇਟੈਂਸੀ ਅਤੇ ਨਾ ਹੀ ਥ੍ਰੁਪੁੱਟ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਇਸ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਟੈਸਟ, ਮਾਈਗ੍ਰੇਸ਼ਨ, ਪੁਨਰ-ਗਣਨਾ, ਅਤੇ ਇੱਕ ਫਾਰਮੈਟ ਤੋਂ ਦੂਜੇ ਫਾਰਮੈਟ ਵਿੱਚ ਡੇਟਾ ਦਾ ਰੂਪਾਂਤਰਨ ਸ਼ਾਮਲ ਹੈ। ਇੱਕ ਪਾਸੇ, ਉਹ ਗਣਨਾ ਕੀਤੇ ਲੋਕਾਂ ਦੇ ਸਮਾਨ ਹਨ, ਦੂਜੇ ਪਾਸੇ, ਇਹ ਸਾਡੇ ਲਈ ਅਸਲ ਵਿੱਚ ਮਾਇਨੇ ਨਹੀਂ ਰੱਖਦਾ ਕਿ ਉਹ ਕਿੰਨੀ ਜਲਦੀ ਪੂਰੇ ਹੋ ਜਾਂਦੇ ਹਨ।

ਆਓ ਦੇਖੀਏ ਕਿ ਅਜਿਹੇ ਕੰਮ ਕਿਵੇਂ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਕਰਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਕੇਂਦਰੀ ਪ੍ਰੋਸੈਸਰ.

ਛੋਟੀ ਦੇਰੀ ਵਾਲੇ ਕੰਮ। ਅਜਿਹੇ ਕੰਮ ਦਾ ਇੱਕ CPU ਖਪਤ ਪੈਟਰਨ ਇਸ ਵਰਗਾ ਹੋਵੇਗਾ:

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

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

alloc: cpu = 4 (max)

ਅਤੇ ਜੇਕਰ ਸਾਡੇ ਕੋਲ 16 ਕੋਰਾਂ ਵਾਲੀ ਮਿਨੀਅਨ ਮਸ਼ੀਨ ਹੈ, ਤਾਂ ਇਸ 'ਤੇ ਬਿਲਕੁਲ ਚਾਰ ਅਜਿਹੇ ਕੰਮ ਰੱਖੇ ਜਾ ਸਕਦੇ ਹਨ। ਅਸੀਂ ਖਾਸ ਤੌਰ 'ਤੇ ਨੋਟ ਕਰਦੇ ਹਾਂ ਕਿ ਅਜਿਹੇ ਕਾਰਜਾਂ ਦੀ ਔਸਤ ਪ੍ਰੋਸੈਸਰ ਦੀ ਖਪਤ ਅਕਸਰ ਬਹੁਤ ਘੱਟ ਹੁੰਦੀ ਹੈ - ਜੋ ਕਿ ਸਪੱਸ਼ਟ ਹੈ, ਕਿਉਂਕਿ ਸਮੇਂ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ ਇੱਕ ਬੇਨਤੀ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ ਅਤੇ ਕੁਝ ਨਹੀਂ ਕਰਦਾ ਹੈ।

ਗਣਨਾ ਦੇ ਕੰਮ। ਉਹਨਾਂ ਦਾ ਪੈਟਰਨ ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਹੋਵੇਗਾ:

ਅਜਿਹੇ ਕੰਮਾਂ ਲਈ ਔਸਤ CPU ਸਰੋਤ ਦੀ ਖਪਤ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਹੈ। ਅਕਸਰ ਅਸੀਂ ਇੱਕ ਗਣਨਾ ਕਾਰਜ ਨੂੰ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮੇਂ ਵਿੱਚ ਪੂਰਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਇਸਲਈ ਸਾਨੂੰ ਲੋੜੀਂਦੇ ਪ੍ਰੋਸੈਸਰਾਂ ਦੀ ਘੱਟੋ-ਘੱਟ ਗਿਣਤੀ ਨੂੰ ਰਿਜ਼ਰਵ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਾਂ ਜੋ ਸਮੁੱਚੀ ਗਣਨਾ ਇੱਕ ਸਵੀਕਾਰਯੋਗ ਸਮੇਂ ਵਿੱਚ ਪੂਰੀ ਹੋ ਸਕੇ। ਇਸਦਾ ਰਿਜ਼ਰਵੇਸ਼ਨ ਫਾਰਮੂਲਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ:

alloc: cpu = [1,*)

"ਕਿਰਪਾ ਕਰਕੇ ਇਸਨੂੰ ਇੱਕ ਮਿਨੀਅਨ 'ਤੇ ਰੱਖੋ ਜਿੱਥੇ ਘੱਟੋ ਘੱਟ ਇੱਕ ਮੁਫਤ ਕੋਰ ਹੈ, ਅਤੇ ਫਿਰ ਜਿੰਨੇ ਵੀ ਹਨ, ਇਹ ਸਭ ਕੁਝ ਖਾ ਜਾਵੇਗਾ।"

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

ਪਰ ਇਹ ਕਿਵੇਂ ਕਰੀਏ?

ਪਹਿਲਾਂ, ਆਓ ਪ੍ਰੋਡ ਅਤੇ ਇਸਦੇ ਐਲੋਕ ਨੂੰ ਵੇਖੀਏ: cpu = 4. ਸਾਨੂੰ ਚਾਰ ਕੋਰ ਰਿਜ਼ਰਵ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਡੌਕਰ ਰਨ ਵਿੱਚ ਇਹ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

• ਵਿਕਲਪ ਦੇ ਨਾਲ --cpuset=1-4, ਯਾਨੀ ਮਸ਼ੀਨ ਉੱਤੇ ਚਾਰ ਖਾਸ ਕੋਰਾਂ ਨੂੰ ਕੰਮ ਲਈ ਨਿਰਧਾਰਤ ਕਰੋ।
• ਵਰਤਣ ਲਈ --cpuquota=400_000 --cpuperiod=100_000, ਪ੍ਰੋਸੈਸਰ ਸਮੇਂ ਲਈ ਇੱਕ ਕੋਟਾ ਨਿਰਧਾਰਤ ਕਰੋ, ਭਾਵ ਇਹ ਦਰਸਾਓ ਕਿ ਹਰ 100 ms ਰੀਅਲ ਟਾਈਮ ਵਿੱਚ ਕਾਰਜ 400 ms ਤੋਂ ਵੱਧ ਪ੍ਰੋਸੈਸਰ ਸਮੇਂ ਦੀ ਖਪਤ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਉਹੀ ਚਾਰ ਕੋਰ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ.

ਪਰ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਤਰੀਕਾ ਢੁਕਵਾਂ ਹੈ?

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

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

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

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

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

one.nio.os.Proc.sched_setscheduler( pid, Proc.SCHED_IDLE )

ਪਰ ਭਾਵੇਂ ਤੁਸੀਂ ਜਾਵਾ ਵਿੱਚ ਪ੍ਰੋਗਰਾਮ ਨਹੀਂ ਕਰਦੇ ਹੋ, ਇਹੀ ਚੀਜ਼ chrt ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ:

chrt -i 0 $pid

ਆਉ ਸਪਸ਼ਟਤਾ ਲਈ ਸਾਡੇ ਸਾਰੇ ਅਲੱਗ-ਥਲੱਗ ਪੱਧਰਾਂ ਨੂੰ ਇੱਕ ਸਾਰਣੀ ਵਿੱਚ ਸੰਖੇਪ ਕਰੀਏ:

ਇਨਸੂਲੇਸ਼ਨ ਕਲਾਸ
Alloc ਉਦਾਹਰਨ
ਡੌਕਰ ਰਨ ਵਿਕਲਪ
sched_setscheduler chrt*

Prod
cpu = 4
--cpuquota=400000 --cpuperiod=100000
SCHED_OTHER

ਬੈਚ
Cpu = [1, *)
--cpushares=1024
SCHED_BATCH

ਨਿਸ਼ਕਿਰਿਆ
CPU = [2, *)
--cpushares=2048
SCHED_IDLE

*ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰੋਂ chrt ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ sys_nice ਸਮਰੱਥਾ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਮੂਲ ਰੂਪ ਵਿੱਚ ਡੌਕਰ ਕੰਟੇਨਰ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਵੇਲੇ ਇਸ ਸਮਰੱਥਾ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ।

ਪਰ ਕੰਮ ਨਾ ਸਿਰਫ ਪ੍ਰੋਸੈਸਰ, ਬਲਕਿ ਟ੍ਰੈਫਿਕ ਦੀ ਵੀ ਖਪਤ ਕਰਦੇ ਹਨ, ਜੋ ਕਿ ਪ੍ਰੋਸੈਸਰ ਸਰੋਤਾਂ ਦੀ ਗਲਤ ਵੰਡ ਤੋਂ ਵੀ ਵੱਧ ਇੱਕ ਨੈਟਵਰਕ ਟਾਸਕ ਦੀ ਲੇਟੈਂਸੀ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ, ਅਸੀਂ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਆਵਾਜਾਈ ਲਈ ਬਿਲਕੁਲ ਉਹੀ ਤਸਵੀਰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ. ਭਾਵ, ਜਦੋਂ ਕੋਈ ਪ੍ਰੋਡ ਟਾਸਕ ਨੈਟਵਰਕ ਨੂੰ ਕੁਝ ਪੈਕੇਟ ਭੇਜਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਵੱਧ ਤੋਂ ਵੱਧ ਗਤੀ ਨੂੰ ਸੀਮਿਤ ਕਰਦੇ ਹਾਂ (ਫਾਰਮੂਲਾ alloc: lan=[*,500mbps) ), ਜਿਸ ਨਾਲ ਉਤਪਾਦ ਇਹ ਕਰ ਸਕਦਾ ਹੈ। ਅਤੇ ਬੈਚ ਲਈ ਅਸੀਂ ਸਿਰਫ ਘੱਟੋ-ਘੱਟ ਥ੍ਰੁਪੁੱਟ ਦੀ ਗਰੰਟੀ ਦਿੰਦੇ ਹਾਂ, ਪਰ ਵੱਧ ਤੋਂ ਵੱਧ (ਫਾਰਮੂਲਾ alloc: lan=[10Mbps,*) ) ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਪ੍ਰੋਡ ਟ੍ਰੈਫਿਕ ਨੂੰ ਬੈਚ ਕਾਰਜਾਂ ਨਾਲੋਂ ਤਰਜੀਹ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇੱਥੇ ਡੌਕਰ ਕੋਲ ਕੋਈ ਵੀ ਪ੍ਰਾਚੀਨ ਨਹੀਂ ਹੈ ਜੋ ਅਸੀਂ ਵਰਤ ਸਕਦੇ ਹਾਂ. ਪਰ ਇਹ ਸਾਡੀ ਮਦਦ ਲਈ ਆਉਂਦਾ ਹੈ ਲੀਨਕਸ ਟ੍ਰੈਫਿਕ ਕੰਟਰੋਲ. ਅਸੀਂ ਅਨੁਸ਼ਾਸਨ ਦੀ ਮਦਦ ਨਾਲ ਲੋੜੀਂਦਾ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਸੀ ਲੜੀਵਾਰ ਨਿਰਪੱਖ ਸੇਵਾ ਵਕਰ. ਇਸਦੀ ਮਦਦ ਨਾਲ, ਅਸੀਂ ਟ੍ਰੈਫਿਕ ਦੀਆਂ ਦੋ ਸ਼੍ਰੇਣੀਆਂ ਨੂੰ ਵੱਖਰਾ ਕਰਦੇ ਹਾਂ: ਉੱਚ-ਪ੍ਰਾਥਮਿਕਤਾ ਪ੍ਰੋਡ ਅਤੇ ਘੱਟ-ਪ੍ਰਾਥਮਿਕਤਾ ਬੈਚ/ਵਿਹਲੇ। ਨਤੀਜੇ ਵਜੋਂ, ਆਊਟਗੋਇੰਗ ਟ੍ਰੈਫਿਕ ਲਈ ਸੰਰਚਨਾ ਇਸ ਤਰ੍ਹਾਂ ਹੈ:

ਇੱਥੇ 1:0 hsfc ਅਨੁਸ਼ਾਸਨ ਦਾ "ਰੂਟ qdisc" ਹੈ; 1:1 - 8 Gbit/s ਦੀ ਕੁੱਲ ਬੈਂਡਵਿਡਥ ਸੀਮਾ ਵਾਲੀ hsfc ਚਾਈਲਡ ਕਲਾਸ, ਜਿਸ ਦੇ ਅਧੀਨ ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਦੀਆਂ ਚਾਈਲਡ ਕਲਾਸਾਂ ਰੱਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ; 1:2 - hsfc ਚਾਈਲਡ ਕਲਾਸ "ਗਤੀਸ਼ੀਲ" ਸੀਮਾ ਵਾਲੇ ਸਾਰੇ ਬੈਚ ਅਤੇ ਨਿਸ਼ਕਿਰਿਆ ਕੰਮਾਂ ਲਈ ਆਮ ਹੈ, ਜਿਸਦੀ ਹੇਠਾਂ ਚਰਚਾ ਕੀਤੀ ਗਈ ਹੈ। ਬਾਕੀ ਬਚੀਆਂ hsfc ਬਾਲ ਕਲਾਸਾਂ ਵਰਤਮਾਨ ਵਿੱਚ ਉਹਨਾਂ ਦੇ ਮੈਨੀਫੈਸਟਾਂ - 450 ਅਤੇ 400 Mbit/s ਨਾਲ ਸੰਬੰਧਿਤ ਸੀਮਾਵਾਂ ਵਾਲੇ ਪ੍ਰੋਡ ਕੰਟੇਨਰਾਂ ਲਈ ਸਮਰਪਿਤ ਕਲਾਸਾਂ ਹਨ। ਹਰੇਕ hsfc ਕਲਾਸ ਨੂੰ ਲੀਨਕਸ ਕਰਨਲ ਵਰਜਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਟ੍ਰੈਫਿਕ ਬਰੱਸਟ ਦੌਰਾਨ ਪੈਕੇਟ ਦੇ ਨੁਕਸਾਨ ਤੋਂ ਬਚਣ ਲਈ, ਇੱਕ qdisc ਕਤਾਰ fq ਜਾਂ fq_codel ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

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

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

ਬੈਂਡਾਂ ਨੂੰ ਆਉਣ ਵਾਲੇ ਅਤੇ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਲਈ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਨਵੇਂ ਮੁੱਲਾਂ ਦੇ ਅਨੁਸਾਰ, miniond ਗੈਰ-ਪ੍ਰਾਥਮਿਕ ਸ਼੍ਰੇਣੀ ਸੀਮਾ 1:2 ਨੂੰ ਮੁੜ ਸੰਰਚਿਤ ਕਰਦਾ ਹੈ।

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

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

ਵਾਧੂ ਲਾਈਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਹਟਾਏ ਜਾਣ ਦੇ ਨਾਲ, ਅਸੀਂ ਪੂਰੇ ਸੇਵਾ ਨਾਮ ਦੇ ਅੰਤ ਵਿੱਚ ਟਾਸਕ ਆਈਸੋਲੇਸ਼ਨ ਕਲਾਸ ਨੂੰ ਜੋੜ ਕੇ ਆਪਣੇ ਸੇਵਾ ਨਾਮਾਂ ਨੂੰ ਫਲੈਟਰ ਲਿਖ ਸਕਦੇ ਹਾਂ: web.front.prod, catalog.music.batch, transformer.music.idle.

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

ਸਭ ਕੁਝ ਬਹੁਤ ਵਧੀਆ ਹੈ, ਪਰ ਇੱਕ ਕੌੜਾ ਸੱਚ ਹੈ। ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲ ਰਹੇ ਕੰਮਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਲੱਗ ਕਰਨਾ ਅਸੰਭਵ ਹੈ।

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

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਹੁਣ ਤੱਕ ਸਿਰਫ TCP ਟ੍ਰੈਫਿਕ ਨੂੰ ਤਰਜੀਹ ਦੇਣ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋਏ ਹਾਂ: hsfc ਪਹੁੰਚ UDP ਲਈ ਕੰਮ ਨਹੀਂ ਕਰਦੀ ਹੈ। ਅਤੇ TCP ਟ੍ਰੈਫਿਕ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਵੀ, ਜੇਕਰ ਬੈਚ ਟਾਸਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਟ੍ਰੈਫਿਕ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਪ੍ਰੋਡ ਟਾਸਕ ਦੀ ਦੇਰੀ ਵਿੱਚ ਲਗਭਗ 10% ਵਾਧਾ ਵੀ ਦਿੰਦਾ ਹੈ।

ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ

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

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

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

ਤੁਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹੋ ਜੇਕਰ ਇੱਕ ਪੂਰਾ ਮਿਨੀਅਨ ਉਪਲਬਧ ਨਹੀਂ ਹੈ?

ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਕੰਟੇਨਰ ਨੂੰ ਕਿਸੇ ਹੋਰ ਮਸ਼ੀਨ 'ਤੇ ਚਲਾਓ. ਇੱਥੇ ਦਿਲਚਸਪ ਹਿੱਸਾ ਇਹ ਹੈ ਕਿ ਕੰਟੇਨਰ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤੇ IP ਐਡਰੈੱਸ ਨਾਲ ਕੀ ਹੁੰਦਾ ਹੈ।

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

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

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

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

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

ਇਸ ਤਰ੍ਹਾਂ, IP ਪਤਿਆਂ ਦੀ ਸੂਚੀ ਵਿੱਚ ਸੇਵਾ ਦੇ ਨਾਮ ਦੀ ਮੈਪਿੰਗ ਬਹੁਤ ਘੱਟ ਹੀ ਬਦਲਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਸੇਵਾ ਦੇ ਉਦਾਹਰਨਾਂ ਦੇ ਨਾਵਾਂ ਨੂੰ ਦੁਬਾਰਾ ਦੇਖਦੇ ਹੋ ਜਿਨ੍ਹਾਂ ਦਾ ਅਸੀਂ ਲੇਖ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਜ਼ਿਕਰ ਕੀਤਾ ਹੈ (1.ok-web.group1.web.front.prod, 2.ok-web.group1.web.front.prod, …), ਅਸੀਂ ਧਿਆਨ ਦੇਵਾਂਗੇ ਕਿ ਉਹ DNS ਵਿੱਚ ਵਰਤੇ ਗਏ FQDN ਦੇ ਸਮਾਨ ਹਨ। ਇਹ ਸਹੀ ਹੈ, ਸੇਵਾ ਉਦਾਹਰਨਾਂ ਦੇ ਨਾਵਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ IP ਪਤਿਆਂ 'ਤੇ ਮੈਪ ਕਰਨ ਲਈ, ਅਸੀਂ DNS ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ DNS ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਦੇ ਸਾਰੇ ਰਿਜ਼ਰਵਡ IP ਐਡਰੈੱਸ ਵਾਪਸ ਕਰਦਾ ਹੈ - ਚੱਲ ਰਹੇ ਅਤੇ ਰੁਕੇ ਦੋਵੇਂ (ਆਓ ਕਹੀਏ ਕਿ ਤਿੰਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਹੈ, ਅਤੇ ਸਾਡੇ ਕੋਲ ਪੰਜ ਪਤੇ ਰਾਖਵੇਂ ਹਨ - ਸਾਰੇ ਪੰਜ ਵਾਪਸ ਕੀਤੇ ਜਾਣਗੇ)। ਗ੍ਰਾਹਕ, ਇਹ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਸਾਰੇ ਪੰਜ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨਾਲ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਗੇ - ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਉਹਨਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਗੇ ਜੋ ਕੰਮ ਕਰ ਰਹੇ ਹਨ। ਉਪਲਬਧਤਾ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਇਹ ਵਿਕਲਪ ਬਹੁਤ ਜ਼ਿਆਦਾ ਭਰੋਸੇਮੰਦ ਹੈ; ਇਸ ਵਿੱਚ ਜਾਂ ਤਾਂ DNS ਜਾਂ ਸੇਵਾ ਖੋਜ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹਨਾਂ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਜਾਣਕਾਰੀ ਦੀ ਸਾਰਥਕਤਾ ਅਤੇ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਵਿੱਚ ਹੱਲ ਕਰਨ ਲਈ ਕੋਈ ਮੁਸ਼ਕਲ ਸਮੱਸਿਆਵਾਂ ਨਹੀਂ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਨਾਜ਼ੁਕ ਸੇਵਾਵਾਂ ਵਿੱਚ ਜਿਨ੍ਹਾਂ 'ਤੇ ਪੂਰੇ ਪੋਰਟਲ ਦਾ ਸੰਚਾਲਨ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਅਸੀਂ DNS ਦੀ ਵਰਤੋਂ ਬਿਲਕੁਲ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਪਰ ਸੰਰਚਨਾ ਵਿੱਚ ਸਿਰਫ਼ IP ਪਤੇ ਦਰਜ ਕਰ ਸਕਦੇ ਹਾਂ।

ਕੰਟੇਨਰਾਂ ਦੇ ਪਿੱਛੇ ਅਜਿਹੇ IP ਟ੍ਰਾਂਸਫਰ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਗੈਰ-ਮਾਮੂਲੀ ਹੋ ਸਕਦਾ ਹੈ - ਅਤੇ ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ ਇਹ ਹੇਠਾਂ ਦਿੱਤੀ ਉਦਾਹਰਣ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ:

ਮੰਨ ਲਓ ਕਿ ਵਨ-ਕਲਾਊਡ ਮਾਸਟਰ ਮਿਨੀਅਨ M1 ਨੂੰ ਚਲਾਉਣ ਲਈ ਕਮਾਂਡ ਦਿੰਦਾ ਹੈ 1.ok-web.group1.web.front.prod ਪਤੇ 1.1.1.1 ਦੇ ਨਾਲ। ਮਿਨੀਅਨ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ BIRD, ਜੋ ਕਿ ਵਿਸ਼ੇਸ਼ ਸਰਵਰਾਂ ਲਈ ਇਸ ਪਤੇ ਦਾ ਇਸ਼ਤਿਹਾਰ ਦਿੰਦਾ ਹੈ ਰੂਟ ਰਿਫਲੈਕਟਰ. ਬਾਅਦ ਵਿੱਚ ਨੈੱਟਵਰਕ ਹਾਰਡਵੇਅਰ ਦੇ ਨਾਲ ਇੱਕ BGP ਸੈਸ਼ਨ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ M1.1.1.1 'ਤੇ ਪਤੇ 1 ਦਾ ਰੂਟ ਅਨੁਵਾਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। M1 ਲੀਨਕਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਪੈਕੇਟਾਂ ਨੂੰ ਰੂਟ ਕਰਦਾ ਹੈ। ਇੱਥੇ ਤਿੰਨ ਰੂਟ ਰਿਫਲੈਕਟਰ ਸਰਵਰ ਹਨ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ-ਕਲਾਊਡ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਇੱਕ ਬਹੁਤ ਹੀ ਨਾਜ਼ੁਕ ਹਿੱਸਾ ਹੈ - ਉਹਨਾਂ ਤੋਂ ਬਿਨਾਂ, ਇੱਕ-ਕਲਾਊਡ ਵਿੱਚ ਨੈੱਟਵਰਕ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ। ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਰੈਕਾਂ ਵਿੱਚ ਰੱਖਦੇ ਹਾਂ, ਜੇਕਰ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਡੇਟਾ ਸੈਂਟਰ ਦੇ ਵੱਖ-ਵੱਖ ਕਮਰਿਆਂ ਵਿੱਚ ਸਥਿਤ, ਇੱਕੋ ਸਮੇਂ ਤੇ ਤਿੰਨੋਂ ਅਸਫਲ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਘਟਾਉਣ ਲਈ।

ਚਲੋ ਹੁਣ ਇਹ ਮੰਨ ਲਈਏ ਕਿ ਵਨ-ਕਲਾਊਡ ਮਾਸਟਰ ਅਤੇ M1 ਮਾਈਨਿਅਨ ਵਿਚਕਾਰ ਕਨੈਕਸ਼ਨ ਖਤਮ ਹੋ ਗਿਆ ਹੈ। ਵਨ-ਕਲਾਊਡ ਮਾਸਟਰ ਹੁਣ ਇਸ ਧਾਰਨਾ 'ਤੇ ਕੰਮ ਕਰੇਗਾ ਕਿ M1 ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸਫਲ ਹੋ ਗਿਆ ਹੈ। ਯਾਨੀ ਇਹ M2 ਮਿਨੀਅਨ ਨੂੰ ਲਾਂਚ ਕਰਨ ਦੀ ਕਮਾਂਡ ਦੇਵੇਗਾ web.group1.web.front.prod ਉਸੇ ਪਤੇ ਨਾਲ 1.1.1.1. ਹੁਣ ਸਾਡੇ ਕੋਲ 1.1.1.1 ਲਈ ਨੈੱਟਵਰਕ 'ਤੇ ਦੋ ਵਿਰੋਧੀ ਰੂਟ ਹਨ: M1 'ਤੇ ਅਤੇ M2 'ਤੇ। ਅਜਿਹੇ ਵਿਵਾਦਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਅਸੀਂ ਮਲਟੀ ਐਗਜ਼ਿਟ ਡਿਸਕਰੀਮੀਨੇਟਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਜੋ ਕਿ BGP ਘੋਸ਼ਣਾ ਵਿੱਚ ਦਰਸਾਏ ਗਏ ਹਨ। ਇਹ ਇੱਕ ਅਜਿਹਾ ਨੰਬਰ ਹੈ ਜੋ ਇਸ਼ਤਿਹਾਰੀ ਰੂਟ ਦਾ ਭਾਰ ਦਰਸਾਉਂਦਾ ਹੈ। ਵਿਰੋਧੀ ਰੂਟਾਂ ਵਿੱਚੋਂ, ਘੱਟ MED ਮੁੱਲ ਵਾਲਾ ਰੂਟ ਚੁਣਿਆ ਜਾਵੇਗਾ। ਵਨ-ਕਲਾਊਡ ਮਾਸਟਰ ਕੰਟੇਨਰ IP ਐਡਰੈੱਸ ਦੇ ਅਨਿੱਖੜਵੇਂ ਹਿੱਸੇ ਵਜੋਂ MED ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਪਹਿਲੀ ਵਾਰ, ਪਤਾ ਕਾਫ਼ੀ ਵੱਡੇ MED = 1 ਨਾਲ ਲਿਖਿਆ ਗਿਆ ਹੈ। ਅਜਿਹੀ ਸੰਕਟਕਾਲੀਨ ਕੰਟੇਨਰ ਟ੍ਰਾਂਸਫਰ ਦੀ ਸਥਿਤੀ ਵਿੱਚ, ਮਾਸਟਰ MED ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ, ਅਤੇ M000 ਪਹਿਲਾਂ ਹੀ MED = ਨਾਲ ਪਤੇ 000 ਦੀ ਮਸ਼ਹੂਰੀ ਕਰਨ ਲਈ ਕਮਾਂਡ ਪ੍ਰਾਪਤ ਕਰੇਗਾ। 2.

ਦੁਰਘਟਨਾਵਾਂ

ਸਾਰੇ ਡਾਟਾ ਸੈਂਟਰ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀਆਂ ਹਮੇਸ਼ਾ ਮਾਮੂਲੀ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਸਵੀਕਾਰਯੋਗ ਢੰਗ ਨਾਲ ਸੰਭਾਲਦੀਆਂ ਹਨ। ਕੰਟੇਨਰ ਓਵਰਫਲੋ ਲਗਭਗ ਹਰ ਜਗ੍ਹਾ ਆਮ ਹੈ.

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

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

ਅਕਸਰ ਹਾਦਸੇ ਕੰਟਰੋਲ ਪਰਤ ਦੀ ਅਸਫਲਤਾ ਦੇ ਨਾਲ ਹੁੰਦੇ ਹਨ. ਇਹ ਇਸਦੇ ਸਾਜ਼-ਸਾਮਾਨ ਦੀ ਅਸਫਲਤਾ ਦੇ ਕਾਰਨ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਅਕਸਰ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਦੁਰਘਟਨਾਵਾਂ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ, ਅਤੇ ਕੰਟਰੋਲ ਲੇਅਰ ਆਪਣੇ ਆਪ ਵਧੇ ਹੋਏ ਲੋਡ ਕਾਰਨ ਡਿੱਗ ਜਾਂਦੀ ਹੈ.

ਤੁਸੀਂ ਇਸ ਸਭ ਬਾਰੇ ਕੀ ਕਰ ਸਕਦੇ ਹੋ?

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

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

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

ਉਤਪਾਦ 'ਤੇ ਅਸੀਂ ਉੱਚ ਤਰਜੀਹਾਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ, 0; ਬੈਚ 'ਤੇ - ਥੋੜਾ ਘੱਟ, 100; ਨਿਸ਼ਕਿਰਿਆ 'ਤੇ - ਇਸ ਤੋਂ ਵੀ ਘੱਟ, 200। ਤਰਜੀਹਾਂ ਲੜੀਵਾਰ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਦਰਜਾਬੰਦੀ ਵਿੱਚ ਹੇਠਲੇ ਸਾਰੇ ਕਾਰਜਾਂ ਦੀ ਅਨੁਸਾਰੀ ਤਰਜੀਹ ਹੋਵੇਗੀ। ਜੇਕਰ ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਪ੍ਰੋਡ ਦੇ ਅੰਦਰ ਕੈਚਾਂ ਨੂੰ ਫਰੰਟਐਂਡ ਤੋਂ ਪਹਿਲਾਂ ਲਾਂਚ ਕੀਤਾ ਜਾਵੇ, ਤਾਂ ਅਸੀਂ ਕੈਸ਼ = 0 ਅਤੇ ਫਰੰਟ ਸਬਕਿਊਜ਼ = 1 ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਾਂ। ਜੇਕਰ, ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਮੁੱਖ ਪੋਰਟਲ ਨੂੰ ਪਹਿਲਾਂ ਮੋਰਚਿਆਂ ਤੋਂ ਲਾਂਚ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਅਤੇ ਸਿਰਫ਼ ਸੰਗੀਤ ਫਰੰਟ ਨੂੰ ਫਿਰ, ਫਿਰ ਅਸੀਂ ਬਾਅਦ ਵਾਲੇ ਨੂੰ ਘੱਟ ਤਰਜੀਹ ਦੇ ਸਕਦੇ ਹਾਂ - 10।

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

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

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

ਪੂਰੇ ਡੀਸੀ ਹਾਦਸੇ

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

ਅਤੇ ਇਹ ਉਹ ਹੈ ਜੋ ਅਸੀਂ ਕਿਸੇ ਨੂੰ #alive ਟਵੀਟ ਕਰਨ ਤੋਂ ਰੋਕਣ ਲਈ ਕਰਦੇ ਹਾਂ।

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

ਇਹ ਪਹੁੰਚ ਨਾ ਸਿਰਫ਼ ਸਰੀਰਕ ਅਸਫਲਤਾ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ, ਸਗੋਂ ਆਪਰੇਟਰ ਦੀ ਗਲਤੀ ਤੋਂ ਵੀ ਬਚਾਅ ਕਰ ਸਕਦੀ ਹੈ।

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

ਨਤੀਜੇ

ਇੱਕ-ਕਲਾਊਡ ਦੀਆਂ ਵਿਲੱਖਣ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ:

• ਸੇਵਾਵਾਂ ਅਤੇ ਕੰਟੇਨਰਾਂ ਲਈ ਲੜੀਵਾਰ ਅਤੇ ਵਿਜ਼ੂਅਲ ਨਾਮਕਰਨ ਸਕੀਮ, ਜੋ ਤੁਹਾਨੂੰ ਬਹੁਤ ਜਲਦੀ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਕੰਮ ਕੀ ਹੈ, ਇਹ ਕਿਸ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ ਅਤੇ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਦੇ ਲਈ ਕੌਣ ਜ਼ਿੰਮੇਵਾਰ ਹੈ।
• ਸਾਨੂੰ ਸਾਡੇ ਲਾਗੂ ਉਤਪਾਦ- ਅਤੇ ਬੈਚ- ਨੂੰ ਜੋੜਨ ਦੀ ਤਕਨੀਕਮਸ਼ੀਨ ਸ਼ੇਅਰਿੰਗ ਦੀ ਕੁਸ਼ਲਤਾ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ minions 'ਤੇ ਕੰਮ. cpuset ਦੀ ਬਜਾਏ ਅਸੀਂ CPU ਕੋਟਾ, ਸ਼ੇਅਰ, CPU ਸ਼ਡਿਊਲਰ ਨੀਤੀਆਂ ਅਤੇ Linux QoS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।
• ਇੱਕੋ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲ ਰਹੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਲੱਗ ਕਰਨਾ ਸੰਭਵ ਨਹੀਂ ਸੀ, ਪਰ ਉਨ੍ਹਾਂ ਦਾ ਆਪਸੀ ਪ੍ਰਭਾਵ 20% ਦੇ ਅੰਦਰ ਰਹਿੰਦਾ ਹੈ।
• ਸੇਵਾਵਾਂ ਨੂੰ ਇੱਕ ਲੜੀ ਵਿੱਚ ਸੰਗਠਿਤ ਕਰਨਾ ਆਟੋਮੈਟਿਕ ਆਫ਼ਤ ਰਿਕਵਰੀ ਦੀ ਵਰਤੋਂ ਨਾਲ ਮਦਦ ਕਰਦਾ ਹੈ ਪਲੇਸਮੈਂਟ ਅਤੇ ਅਗਾਊਂ ਤਰਜੀਹਾਂ.

ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਪ੍ਰਸ਼ਨ

ਅਸੀਂ ਇੱਕ ਰੈਡੀਮੇਡ ਹੱਲ ਕਿਉਂ ਨਹੀਂ ਲਿਆ?

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

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

ਆਖਰੀ ਲਾਈਨਾਂ ਪੜ੍ਹਨ ਵਾਲਿਆਂ ਲਈ, ਤੁਹਾਡੇ ਧੀਰਜ ਅਤੇ ਧਿਆਨ ਲਈ ਧੰਨਵਾਦ!

ਸਰੋਤ: www.habr.com