ਕਮਜ਼ੋਰੀਆਂ ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ ਜੋ ਕੰਮ ਦੇ ਦੌਰ ਲਿਆਉਂਦੇ ਹਨ। ਭਾਗ 1: FragmentSmack/SegmentSmack

ਸਾਰਿਆਂ ਨੂੰ ਸਤਿ ਸ਼੍ਰੀ ਅਕਾਲ! ਮੇਰਾ ਨਾਮ ਦਮਿਤਰੀ ਸੈਮਸੋਨੋਵ ਹੈ, ਮੈਂ ਓਡਨੋਕਲਾਸਨੀਕੀ ਵਿੱਚ ਇੱਕ ਪ੍ਰਮੁੱਖ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹਾਂ। ਸਾਡੇ ਕੋਲ 7 ਹਜ਼ਾਰ ਤੋਂ ਵੱਧ ਭੌਤਿਕ ਸਰਵਰ, ਸਾਡੇ ਕਲਾਉਡ ਵਿੱਚ 11 ਹਜ਼ਾਰ ਕੰਟੇਨਰ ਅਤੇ 200 ਐਪਲੀਕੇਸ਼ਨ ਹਨ, ਜੋ ਕਿ ਵੱਖ-ਵੱਖ ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ 700 ਵੱਖ-ਵੱਖ ਕਲੱਸਟਰ ਬਣਾਉਂਦੇ ਹਨ। ਸਰਵਰ ਦੀ ਵੱਡੀ ਬਹੁਗਿਣਤੀ CentOS 7 ਨੂੰ ਚਲਾਉਂਦੀ ਹੈ.
14 ਅਗਸਤ, 2018 ਨੂੰ, FragmentSmack ਕਮਜ਼ੋਰੀ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤੀ ਗਈ ਸੀ
(CVE-2018-5391) ਅਤੇ ਸੈਗਮੈਂਟਸਮੈਕ (CVE-2018-5390). ਇਹ ਇੱਕ ਨੈਟਵਰਕ ਅਟੈਕ ਵੈਕਟਰ ਅਤੇ ਇੱਕ ਕਾਫ਼ੀ ਉੱਚ ਸਕੋਰ (7.5) ਦੇ ਨਾਲ ਕਮਜ਼ੋਰੀਆਂ ਹਨ, ਜੋ ਸਰੋਤ ਥਕਾਵਟ (CPU) ਦੇ ਕਾਰਨ ਸੇਵਾ ਤੋਂ ਇਨਕਾਰ (DoS) ਦੀ ਧਮਕੀ ਦਿੰਦੀਆਂ ਹਨ। FragmentSmack ਲਈ ਇੱਕ ਕਰਨਲ ਫਿਕਸ ਉਸ ਸਮੇਂ ਪ੍ਰਸਤਾਵਿਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ; ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਕਮਜ਼ੋਰੀ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦੇ ਪ੍ਰਕਾਸ਼ਨ ਤੋਂ ਬਹੁਤ ਬਾਅਦ ਵਿੱਚ ਸਾਹਮਣੇ ਆਇਆ ਸੀ। ਸੈਗਮੈਂਟਸਮੈਕ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ, ਕਰਨਲ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਦਾ ਸੁਝਾਅ ਦਿੱਤਾ ਗਿਆ ਸੀ। ਅਪਡੇਟ ਪੈਕੇਜ ਆਪਣੇ ਆਪ ਉਸੇ ਦਿਨ ਜਾਰੀ ਕੀਤਾ ਗਿਆ ਸੀ, ਜੋ ਬਾਕੀ ਬਚਿਆ ਸੀ ਇਸਨੂੰ ਸਥਾਪਿਤ ਕਰਨਾ ਸੀ।
ਨਹੀਂ, ਅਸੀਂ ਕਰਨਲ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਦੇ ਵਿਰੁੱਧ ਨਹੀਂ ਹਾਂ! ਹਾਲਾਂਕਿ, ਇੱਥੇ ਸੂਖਮਤਾਵਾਂ ਹਨ ...

ਅਸੀਂ ਉਤਪਾਦਨ 'ਤੇ ਕਰਨਲ ਨੂੰ ਕਿਵੇਂ ਅਪਡੇਟ ਕਰਦੇ ਹਾਂ

ਆਮ ਤੌਰ 'ਤੇ, ਕੁਝ ਵੀ ਗੁੰਝਲਦਾਰ ਨਹੀਂ ਹੈ:

1. ਪੈਕੇਜ ਡਾਊਨਲੋਡ ਕਰੋ;
2. ਉਹਨਾਂ ਨੂੰ ਕਈ ਸਰਵਰਾਂ 'ਤੇ ਸਥਾਪਿਤ ਕਰੋ (ਸਾਡੇ ਕਲਾਉਡ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਨ ਵਾਲੇ ਸਰਵਰਾਂ ਸਮੇਤ);
3. ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਕੁਝ ਵੀ ਟੁੱਟਿਆ ਨਹੀਂ ਹੈ;
4. ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਸਾਰੀਆਂ ਮਿਆਰੀ ਕਰਨਲ ਸੈਟਿੰਗਾਂ ਗਲਤੀਆਂ ਤੋਂ ਬਿਨਾਂ ਲਾਗੂ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ;
5. ਕੁਝ ਦਿਨ ਉਡੀਕ ਕਰੋ;
6. ਸਰਵਰ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਦੀ ਜਾਂਚ ਕਰੋ;
7. ਨਵੇਂ ਸਰਵਰਾਂ ਦੀ ਤੈਨਾਤੀ ਨੂੰ ਨਵੇਂ ਕਰਨਲ ਵਿੱਚ ਬਦਲੋ;
8. ਡੇਟਾ ਸੈਂਟਰ ਦੁਆਰਾ ਸਾਰੇ ਸਰਵਰਾਂ ਨੂੰ ਅਪਡੇਟ ਕਰੋ (ਸਮੱਸਿਆਵਾਂ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਉਪਭੋਗਤਾਵਾਂ 'ਤੇ ਪ੍ਰਭਾਵ ਨੂੰ ਘੱਟ ਕਰਨ ਲਈ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਡੇਟਾ ਸੈਂਟਰ);
9. ਸਾਰੇ ਸਰਵਰ ਰੀਬੂਟ ਕਰੋ।

ਸਾਡੇ ਕੋਲ ਕਰਨਲ ਦੀਆਂ ਸਾਰੀਆਂ ਸ਼ਾਖਾਵਾਂ ਲਈ ਦੁਹਰਾਓ। ਇਸ ਸਮੇਂ ਇਹ ਹੈ:

• ਸਟਾਕ CentOS 7 3.10 - ਜ਼ਿਆਦਾਤਰ ਨਿਯਮਤ ਸਰਵਰਾਂ ਲਈ;
• ਵਨੀਲਾ 4.19 - ਸਾਡੇ ਲਈ ਇੱਕ-ਬੱਦਲ ਬੱਦਲ, ਕਿਉਂਕਿ ਸਾਨੂੰ BFQ, BBR, ਆਦਿ ਦੀ ਲੋੜ ਹੈ;
• Elrepo kernel-ml 5.2 - ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡ ਕੀਤੇ ਵਿਤਰਕ, ਕਿਉਂਕਿ 4.19 ਅਸਥਿਰ ਵਿਵਹਾਰ ਕਰਦਾ ਸੀ, ਪਰ ਉਹੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਲੋੜ ਹੈ।

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

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

FragmentSmack/SegmentSmack। ਕੰਮਕਾਜ

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

FragmentSmack/SegmentSmack ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਪ੍ਰਸਤਾਵਿਤ ਕੀਤਾ ਗਿਆ ਸੀ ਇਹ ਹੱਲ:

«ਤੁਸੀਂ net.ipv4.ipfrag_high_thresh ਅਤੇ net.ipv3.ipfrag_low_thresh (ਅਤੇ ipv4 net.ipv4.ipfrag_high_thresh ਅਤੇ net.ipv6.ipfrag_high_thresh ਅਤੇ net.ipv6.ipfrag_low_thresh ਲਈ ਉਹਨਾਂ ਦੇ ਹਮਰੁਤਬਾ) ਵਿੱਚ 6MB ਅਤੇ 256MB ਦੇ ਡਿਫਾਲਟ ਮੁੱਲਾਂ ਨੂੰ kB192 kB262144 ਜਾਂ kB64ive ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ। ਘੱਟ ਟੈਸਟ ਹਾਰਡਵੇਅਰ, ਸੈਟਿੰਗਾਂ ਅਤੇ ਸ਼ਰਤਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ ਹਮਲੇ ਦੌਰਾਨ CPU ਵਰਤੋਂ ਵਿੱਚ ਛੋਟੀਆਂ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਕਮੀਆਂ ਦਿਖਾਉਂਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ipfrag_high_thresh=XNUMX ਬਾਈਟਾਂ ਦੇ ਕਾਰਨ ਕੁਝ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਭਾਵ ਹੋ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਸਿਰਫ਼ ਦੋ XNUMXK ਟੁਕੜੇ ਹੀ ਮੁੜ-ਅਸੈਂਬਲੀ ਕਤਾਰ ਵਿੱਚ ਫਿੱਟ ਹੋ ਸਕਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਜੋਖਮ ਹੈ ਕਿ ਵੱਡੇ UDP ਪੈਕੇਟਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਟੁੱਟ ਜਾਣਗੀਆਂ".

ਪੈਰਾਮੀਟਰ ਆਪਣੇ ਆਪ ਨੂੰ ਕਰਨਲ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ:

ipfrag_high_thresh - LONG INTEGER
    Maximum memory used to reassemble IP fragments.

ipfrag_low_thresh - LONG INTEGER
    Maximum memory used to reassemble IP fragments before the kernel
    begins to remove incomplete fragment queues to free up resources.
    The kernel still accepts new fragments for defragmentation.

ਸਾਡੇ ਕੋਲ ਉਤਪਾਦਨ ਸੇਵਾਵਾਂ 'ਤੇ ਵੱਡੇ UDP ਨਹੀਂ ਹਨ। LAN 'ਤੇ ਕੋਈ ਖੰਡਿਤ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਹੈ; WAN 'ਤੇ ਖੰਡਿਤ ਟ੍ਰੈਫਿਕ ਹੈ, ਪਰ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ। ਕੋਈ ਸੰਕੇਤ ਨਹੀਂ ਹਨ - ਤੁਸੀਂ ਵਰਕਅਰਾਉਂਡ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰ ਸਕਦੇ ਹੋ!

FragmentSmack/SegmentSmack। ਪਹਿਲਾ ਖੂਨ

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

ਹੋਸਟ 'ਤੇ Sysctl ਲਾਗੂ ਕਰਨਾ ਕਾਫ਼ੀ ਕਿਉਂ ਨਹੀਂ ਹੈ? ਕੰਟੇਨਰ ਇਸ ਦੇ ਆਪਣੇ ਸਮਰਪਿਤ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਘੱਟੋ-ਘੱਟ ਨੈੱਟਵਰਕ Sysctl ਪੈਰਾਮੀਟਰਾਂ ਦਾ ਹਿੱਸਾ ਕੰਟੇਨਰ ਵਿੱਚ ਹੋਸਟ ਤੋਂ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ।

Sysctl ਸੈਟਿੰਗਾਂ ਕੰਟੇਨਰ ਵਿੱਚ ਕਿਵੇਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ? ਕਿਉਂਕਿ ਸਾਡੇ ਕੰਟੇਨਰ ਗੈਰ-ਅਧਿਕਾਰਤ ਹਨ, ਤੁਸੀਂ ਕੰਟੇਨਰ ਵਿੱਚ ਜਾ ਕੇ ਕਿਸੇ ਵੀ Sysctl ਸੈਟਿੰਗ ਨੂੰ ਬਦਲਣ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੋਗੇ - ਤੁਹਾਡੇ ਕੋਲ ਲੋੜੀਂਦੇ ਅਧਿਕਾਰ ਨਹੀਂ ਹਨ। ਕੰਟੇਨਰਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ, ਸਾਡੇ ਕਲਾਉਡ ਨੇ ਉਸ ਸਮੇਂ ਡੌਕਰ (ਹੁਣ ਪੋਡਮੈਨ). ਨਵੇਂ ਕੰਟੇਨਰ ਦੇ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ API ਰਾਹੀਂ ਡੌਕਰ ਨੂੰ ਪਾਸ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਿਸ ਵਿੱਚ ਜ਼ਰੂਰੀ Sysctl ਸੈਟਿੰਗਾਂ ਸ਼ਾਮਲ ਹਨ।
ਸੰਸਕਰਣਾਂ ਦੀ ਖੋਜ ਕਰਦੇ ਸਮੇਂ, ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਡੌਕਰ API ਨੇ ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਵਾਪਸ ਨਹੀਂ ਕੀਤੀਆਂ (ਘੱਟੋ ਘੱਟ ਸੰਸਕਰਣ 1.10 ਵਿੱਚ)। ਜਦੋਂ ਅਸੀਂ "ਡੌਕਰ ਰਨ" ਦੁਆਰਾ ਕੰਟੇਨਰ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਤਾਂ ਅਸੀਂ ਅੰਤ ਵਿੱਚ ਘੱਟੋ ਘੱਟ ਕੁਝ ਦੇਖਿਆ:

write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.

ਪੈਰਾਮੀਟਰ ਮੁੱਲ ਵੈਧ ਨਹੀਂ ਹੈ। ਲੇਕਿਨ ਕਿਉਂ? ਅਤੇ ਇਹ ਕੇਵਲ ਕਦੇ-ਕਦਾਈਂ ਹੀ ਵੈਧ ਕਿਉਂ ਨਹੀਂ ਹੁੰਦਾ? ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਡੌਕਰ ਉਸ ਕ੍ਰਮ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ ਜਿਸ ਵਿੱਚ Sysctl ਪੈਰਾਮੀਟਰ ਲਾਗੂ ਕੀਤੇ ਗਏ ਹਨ (ਨਵੀਨਤਮ ਟੈਸਟ ਕੀਤਾ ਗਿਆ ਸੰਸਕਰਣ 1.13.1 ਹੈ), ਇਸਲਈ ਕਈ ਵਾਰ ipfrag_high_thresh ਨੇ 256K 'ਤੇ ਸੈੱਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਦੋਂ ipfrag_low_thresh ਅਜੇ ਵੀ 3M ਸੀ, ਯਾਨੀ ਉੱਪਰਲੀ ਸੀਮਾ ਘੱਟ ਸੀ। ਹੇਠਲੀ ਸੀਮਾ ਤੋਂ ਵੱਧ, ਜਿਸ ਨਾਲ ਗਲਤੀ ਹੋਈ।

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

FragmentSmack/SegmentSmack। ਪਹਿਲਾ ਖੂਨ 2

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

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

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

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

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

ਧਾਰਨਾ ਸਧਾਰਨ ਸੀ: ਜੇ ਉਹ ਗ੍ਰਾਫਾਂ 'ਤੇ ਇੱਕੋ ਜਿਹੇ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਦਾ ਇੱਕੋ ਕਾਰਨ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਸ ਕਿਸਮ ਦੀ ਮੈਮੋਰੀ ਨਾਲ ਕੋਈ ਸਮੱਸਿਆ ਬਹੁਤ ਘੱਟ ਹੁੰਦੀ ਹੈ।

ਸਥਿਰ ਸਮੱਸਿਆ ਦਾ ਸਾਰ ਇਹ ਸੀ ਕਿ ਅਸੀਂ QoS ਵਿੱਚ ਡਿਫੌਲਟ ਸੈਟਿੰਗਾਂ ਦੇ ਨਾਲ fq ਪੈਕੇਟ ਸ਼ਡਿਊਲਰ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ। ਮੂਲ ਰੂਪ ਵਿੱਚ, ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਲਈ, ਇਹ ਤੁਹਾਨੂੰ ਕਤਾਰ ਵਿੱਚ 100 ਪੈਕੇਟ ਜੋੜਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਕੁਨੈਕਸ਼ਨ, ਚੈਨਲ ਦੀ ਘਾਟ ਦੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ, ਸਮਰੱਥਾ ਤੱਕ ਕਤਾਰ ਨੂੰ ਬੰਦ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਨ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਪੈਕੇਟ ਸੁੱਟੇ ਜਾਂਦੇ ਹਨ. tc ਅੰਕੜਿਆਂ (tc -s qdisc) ਵਿੱਚ ਇਸਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ:

qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
 Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
  1024 flows (1021 inactive, 0 throttled)
  0 gc, 0 highprio, 0 throttled, 464545 flows_plimit

“464545 flows_plimit” ਇੱਕ ਕਨੈਕਸ਼ਨ ਦੀ ਕਤਾਰ ਸੀਮਾ ਤੋਂ ਵੱਧ ਜਾਣ ਕਾਰਨ ਛੱਡੇ ਗਏ ਪੈਕੇਟ ਹਨ, ਅਤੇ “ਡਰਾਪ 464545” ਇਸ ਸ਼ਡਿਊਲਰ ਦੇ ਸਾਰੇ ਸੁੱਟੇ ਗਏ ਪੈਕੇਟਾਂ ਦਾ ਜੋੜ ਹੈ। ਕਤਾਰ ਦੀ ਲੰਬਾਈ ਨੂੰ ਵਧਾ ਕੇ 1 ਹਜ਼ਾਰ ਕਰਨ ਅਤੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਸਮੱਸਿਆ ਆਉਣੀ ਬੰਦ ਹੋ ਗਈ। ਤੁਸੀਂ ਪਿੱਛੇ ਬੈਠ ਕੇ ਸਮੂਦੀ ਪੀ ਸਕਦੇ ਹੋ।

FragmentSmack/SegmentSmack। ਆਖਰੀ ਖੂਨ

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

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

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

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

ਸਮੱਸਿਆਵਾਂ ਲਈ ਸੰਵਾਦ ਇਸ ਤਰ੍ਹਾਂ ਸੀ (Nginx ਪ੍ਰੌਕਸੀ ਸਾਈਡ 'ਤੇ ਸਥਿਰ):

1. ਕਲਾਇੰਟ: ਇੱਕ ਫਾਈਲ ਡਾਊਨਲੋਡ ਕਰਨ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਬੇਨਤੀ।
2. ਜਾਵਾ ਸਰਵਰ: ਜਵਾਬ.
3. ਕਲਾਇੰਟ: ਫਾਈਲ ਦੇ ਨਾਲ ਪੋਸਟ ਕਰੋ।
4. Java ਸਰਵਰ: ਗਲਤੀ।

ਉਸੇ ਸਮੇਂ, ਜਾਵਾ ਸਰਵਰ ਲੌਗ ਨੂੰ ਲਿਖਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਤੋਂ 0 ਬਾਈਟ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ Nginx ਪ੍ਰੌਕਸੀ ਲਿਖਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਵਿੱਚ 30 ਸਕਿੰਟਾਂ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੱਗਿਆ (30 ਸਕਿੰਟ ਕਲਾਇੰਟ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਸਮਾਂ ਸਮਾਪਤ ਹੈ)। ਸਮਾਂ ਸਮਾਪਤ ਕਿਉਂ ਅਤੇ 0 ਬਾਈਟਸ ਕਿਉਂ? ਇੱਕ HTTP ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਸਭ ਕੁਝ ਉਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਫਾਈਲ ਦੇ ਨਾਲ POST ਨੈੱਟਵਰਕ ਤੋਂ ਅਲੋਪ ਹੁੰਦਾ ਜਾਪਦਾ ਹੈ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਕਲਾਇੰਟ ਅਤੇ Nginx ਦੇ ਵਿਚਕਾਰ ਅਲੋਪ ਹੋ ਜਾਂਦਾ ਹੈ. ਇਹ Tcpdump ਨਾਲ ਆਪਣੇ ਆਪ ਨੂੰ ਹਥਿਆਰਬੰਦ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ! ਪਰ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਨੈੱਟਵਰਕ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ। Nginx ਪ੍ਰੌਕਸੀ L3 ਬੈਲੇਂਸਰ ਦੇ ਪਿੱਛੇ ਹੈ NFware. L3 ਬੈਲੇਂਸਰ ਤੋਂ ਸਰਵਰ ਤੱਕ ਪੈਕੇਟ ਪਹੁੰਚਾਉਣ ਲਈ ਟਨਲਿੰਗ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਇਸਦੇ ਸਿਰਲੇਖਾਂ ਨੂੰ ਪੈਕੇਟਾਂ ਵਿੱਚ ਜੋੜਦਾ ਹੈ:

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਨੈਟਵਰਕ ਇਸ ਸਰਵਰ ਤੇ Vlan-ਟੈਗਡ ਟ੍ਰੈਫਿਕ ਦੇ ਰੂਪ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਜੋ ਪੈਕੇਟਾਂ ਵਿੱਚ ਇਸਦੇ ਆਪਣੇ ਖੇਤਰਾਂ ਨੂੰ ਵੀ ਜੋੜਦਾ ਹੈ:

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

ਇੱਕ ਵਾਰ ਫਿਰ: ਪੈਕੇਟ ਇੱਕ Vlan ਟੈਗ ਦੇ ਨਾਲ ਇਨਕੈਪਸਲੇਟ ਕੀਤੇ ਗਏ ਹਨ, ਇੱਕ ਸੁਰੰਗ ਦੇ ਨਾਲ ਐਨਕੈਪਸੂਲੇਟ ਕੀਤੇ ਗਏ ਹਨ, ਖੰਡਿਤ ਹਨ। ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਇਹ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ, ਆਉ ਗਾਹਕ ਤੋਂ Nginx ਪ੍ਰੌਕਸੀ ਤੱਕ ਪੈਕੇਟ ਰੂਟ ਨੂੰ ਟਰੇਸ ਕਰੀਏ.

1. ਪੈਕੇਟ L3 ਬੈਲੇਂਸਰ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਡਾਟਾ ਸੈਂਟਰ ਦੇ ਅੰਦਰ ਸਹੀ ਰੂਟਿੰਗ ਲਈ, ਪੈਕੇਟ ਨੂੰ ਇੱਕ ਸੁਰੰਗ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਨੈਟਵਰਕ ਕਾਰਡ ਨੂੰ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ।
2. ਕਿਉਂਕਿ ਪੈਕੇਟ + ਟਨਲ ਹੈਡਰ MTU ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਪੈਕੇਟ ਨੂੰ ਟੁਕੜਿਆਂ ਵਿੱਚ ਕੱਟਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਨੈੱਟਵਰਕ ਨੂੰ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ।
3. L3 ਬੈਲੇਂਸਰ ਤੋਂ ਬਾਅਦ ਸਵਿੱਚ, ਜਦੋਂ ਇੱਕ ਪੈਕੇਟ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਇਸ ਵਿੱਚ ਇੱਕ Vlan ਟੈਗ ਜੋੜਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਭੇਜਦਾ ਹੈ।
4. Nginx ਪ੍ਰੌਕਸੀ ਦੇ ਸਾਹਮਣੇ ਸਵਿੱਚ (ਪੋਰਟ ਸੈਟਿੰਗਾਂ ਦੇ ਅਧਾਰ ਤੇ) ਵੇਖਦਾ ਹੈ ਕਿ ਸਰਵਰ ਇੱਕ Vlan-encapsulated ਪੈਕੇਟ ਦੀ ਉਮੀਦ ਕਰ ਰਿਹਾ ਹੈ, ਇਸਲਈ ਇਹ Vlan ਟੈਗ ਨੂੰ ਹਟਾਏ ਬਿਨਾਂ, ਇਸਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਭੇਜਦਾ ਹੈ.
5. ਲੀਨਕਸ ਵਿਅਕਤੀਗਤ ਪੈਕੇਜਾਂ ਦੇ ਟੁਕੜੇ ਲੈਂਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਵੱਡੇ ਪੈਕੇਜ ਵਿੱਚ ਮਿਲਾਉਂਦਾ ਹੈ।
6. ਅੱਗੇ, ਪੈਕੇਟ Vlan ਇੰਟਰਫੇਸ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਜਿੱਥੇ ਇਸ ਤੋਂ ਪਹਿਲੀ ਪਰਤ ਹਟਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ - Vlan encapsulation.
7. ਲੀਨਕਸ ਫਿਰ ਇਸਨੂੰ ਟਨਲ ਇੰਟਰਫੇਸ ਤੇ ਭੇਜਦਾ ਹੈ, ਜਿੱਥੇ ਇਸ ਤੋਂ ਇੱਕ ਹੋਰ ਪਰਤ ਹਟਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ - ਟਨਲ ਇਨਕੈਪਸੂਲੇਸ਼ਨ।

ਮੁਸ਼ਕਲ ਇਹ ਹੈ ਕਿ ਇਹ ਸਭ ਕੁਝ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ tcpdump ਵਿੱਚ ਪਾਸ ਕਰਨਾ ਹੈ।
ਆਉ ਅੰਤ ਤੋਂ ਸ਼ੁਰੂ ਕਰੀਏ: ਕੀ ਗਾਹਕਾਂ ਤੋਂ ਸਾਫ਼ (ਬੇਲੋੜੇ ਸਿਰਲੇਖਾਂ ਤੋਂ ਬਿਨਾਂ) ਆਈਪੀ ਪੈਕੇਟ ਹਨ, ਜਿਸ ਵਿੱਚ ਵੀਲੈਨ ਅਤੇ ਟਨਲ ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਹਟਾਏ ਗਏ ਹਨ?

tcpdump host <ip клиента>

ਨਹੀਂ, ਸਰਵਰ 'ਤੇ ਅਜਿਹੇ ਕੋਈ ਪੈਕੇਜ ਨਹੀਂ ਸਨ। ਇਸ ਲਈ ਸਮੱਸਿਆ ਪਹਿਲਾਂ ਹੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ. ਕੀ ਸਿਰਫ਼ Vlan encapsulation ਵਾਲੇ ਕੋਈ ਪੈਕੇਟ ਹਟਾਏ ਗਏ ਹਨ?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx ਹੈਕਸ ਫਾਰਮੈਟ ਵਿੱਚ ਕਲਾਇੰਟ IP ਪਤਾ ਹੈ।
32:4 — ਫੀਲਡ ਦਾ ਪਤਾ ਅਤੇ ਲੰਬਾਈ ਜਿਸ ਵਿੱਚ SCR IP Tunnel ਪੈਕੇਟ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ।

ਫੀਲਡ ਐਡਰੈੱਸ ਨੂੰ ਬਰੂਟ ਫੋਰਸ ਦੁਆਰਾ ਚੁਣਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਸੀ, ਕਿਉਂਕਿ ਇੰਟਰਨੈਟ 'ਤੇ ਉਹ 40, 44, 50, 54 ਲਿਖਦੇ ਹਨ, ਪਰ ਉੱਥੇ ਕੋਈ IP ਐਡਰੈੱਸ ਨਹੀਂ ਸੀ। ਤੁਸੀਂ ਹੈਕਸ ਵਿੱਚ ਇੱਕ ਪੈਕੇਟ (tcpdump ਵਿੱਚ -xx ਜਾਂ -XX ਪੈਰਾਮੀਟਰ) ਨੂੰ ਵੀ ਦੇਖ ਸਕਦੇ ਹੋ ਅਤੇ ਉਸ IP ਪਤੇ ਦੀ ਗਣਨਾ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ।

ਕੀ Vlan ਅਤੇ Tunnel encapsulation ਦੇ ਬਿਨਾਂ ਪੈਕੇਟ ਦੇ ਟੁਕੜੇ ਹਨ?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))

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

14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500)
    11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
    33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
        0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
        0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
        0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected].
        0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
        0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.......
        0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx
        0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........

14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40)
    11.11.11.11 > 22.22.22.22: ip-proto-4
        0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
        0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
        0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
        0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
        0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............

ਇਹ ਇੱਕ ਪੈਕੇਜ ਦੇ ਦੋ ਟੁਕੜੇ ਹਨ (ਇੱਕੋ ID 53652) ਇੱਕ ਫੋਟੋ ਦੇ ਨਾਲ (ਪਹਿਲੇ ਪੈਕੇਜ ਵਿੱਚ Exif ਸ਼ਬਦ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ)। ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਕਿ ਇਸ ਪੱਧਰ 'ਤੇ ਪੈਕੇਜ ਹਨ, ਪਰ ਡੰਪਾਂ ਵਿੱਚ ਵਿਲੀਨ ਰੂਪ ਵਿੱਚ ਨਹੀਂ, ਸਮੱਸਿਆ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਅਸੈਂਬਲੀ ਦੇ ਨਾਲ ਹੈ. ਅੰਤ ਵਿੱਚ ਇਸ ਦਾ ਦਸਤਾਵੇਜ਼ੀ ਸਬੂਤ ਹੈ!

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

netstat -s | grep "packet reassembles failed”

ਇਹ snmpd ਵਿੱਚ OID=1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).

"IP ਰੀ-ਅਸੈਂਬਲੀ ਐਲਗੋਰਿਦਮ ਦੁਆਰਾ ਖੋਜੀਆਂ ਗਈਆਂ ਅਸਫਲਤਾਵਾਂ ਦੀ ਸੰਖਿਆ (ਕਿਸੇ ਵੀ ਕਾਰਨ ਕਰਕੇ: ਸਮਾਂ ਸਮਾਪਤ, ਗਲਤੀਆਂ, ਆਦਿ)।"

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

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

ਅਸੀਂ ਦੂਜੇ ਸਰਵਰਾਂ 'ਤੇ ਫ੍ਰੈਗਮੈਂਟੇਸ਼ਨ ਸੈਟਿੰਗਾਂ ਨੂੰ ਵਾਪਸ ਲਿਆ, ਜਿੱਥੇ ਨਵੀਂ ਨਿਗਰਾਨੀ ਲਾਗੂ ਹੋਈ, ਅਤੇ ਕਿਤੇ ਅਸੀਂ ਫ੍ਰੈਗਮੈਂਟਸ ਲਈ ਪਹਿਲਾਂ ਡਿਫੌਲਟ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਕੀਤੀ (ਇਹ UDP ਅੰਕੜੇ ਸਨ, ਜਿਸ ਦਾ ਅੰਸ਼ਕ ਨੁਕਸਾਨ ਆਮ ਪਿਛੋਕੜ ਦੇ ਵਿਰੁੱਧ ਧਿਆਨ ਦੇਣ ਯੋਗ ਨਹੀਂ ਸੀ) .

ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਸਵਾਲ

ਸਾਡੇ L3 ਬੈਲੈਂਸਰ 'ਤੇ ਪੈਕੇਟ ਕਿਉਂ ਟੁੱਟੇ ਹੋਏ ਹਨ? ਜ਼ਿਆਦਾਤਰ ਪੈਕੇਟ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਤੋਂ ਬੈਲੇਂਸਰਾਂ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ SYN ਅਤੇ ACK ਹਨ। ਇਹਨਾਂ ਪੈਕੇਜਾਂ ਦੇ ਆਕਾਰ ਛੋਟੇ ਹਨ। ਪਰ ਕਿਉਂਕਿ ਅਜਿਹੇ ਪੈਕਟਾਂ ਦਾ ਹਿੱਸਾ ਬਹੁਤ ਵੱਡਾ ਹੈ, ਉਹਨਾਂ ਦੇ ਪਿਛੋਕੜ ਦੇ ਵਿਰੁੱਧ ਅਸੀਂ ਵੱਡੇ ਪੈਕੇਟਾਂ ਦੀ ਮੌਜੂਦਗੀ ਵੱਲ ਧਿਆਨ ਨਹੀਂ ਦਿੱਤਾ ਜੋ ਟੁਕੜੇ ਹੋਣੇ ਸ਼ੁਰੂ ਹੋ ਗਏ ਸਨ।

ਕਾਰਨ ਇੱਕ ਟੁੱਟੀ ਸੰਰਚਨਾ ਸਕ੍ਰਿਪਟ ਸੀ advmss Vlan ਇੰਟਰਫੇਸ ਵਾਲੇ ਸਰਵਰਾਂ 'ਤੇ (ਉਸ ਸਮੇਂ ਉਤਪਾਦਨ ਵਿੱਚ ਟੈਗ ਕੀਤੇ ਟ੍ਰੈਫਿਕ ਵਾਲੇ ਬਹੁਤ ਘੱਟ ਸਰਵਰ ਸਨ)। Advmss ਸਾਨੂੰ ਗਾਹਕ ਨੂੰ ਇਹ ਜਾਣਕਾਰੀ ਦੇਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਸਾਡੀ ਦਿਸ਼ਾ ਵਿੱਚ ਪੈਕੇਟ ਆਕਾਰ ਵਿੱਚ ਛੋਟੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਤਾਂ ਜੋ ਉਹਨਾਂ ਨਾਲ ਸੁਰੰਗ ਹੈਡਰਾਂ ਨੂੰ ਜੋੜਨ ਤੋਂ ਬਾਅਦ ਉਹਨਾਂ ਨੂੰ ਟੁਕੜੇ ਨਾ ਕਰਨਾ ਪਵੇ।

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

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

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

ਸਰੋਤ: www.habr.com