ਕਲਾਉਡ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਨੈੱਟਵਰਕ ਹਿੱਸੇ ਦੀ ਜਾਣ-ਪਛਾਣ

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

ਅੱਜ ਅਸੀਂ ਕਲਾਉਡ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਅੰਦਰੂਨੀ ਦੁਨੀਆਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ, ਖਾਸ ਤੌਰ 'ਤੇ ਅਸੀਂ ਨੈੱਟਵਰਕ ਹਿੱਸੇ ਦੀਆਂ ਮੂਲ ਗੱਲਾਂ ਨੂੰ ਦੇਖਾਂਗੇ।

ਇੱਕ ਬੱਦਲ ਕੀ ਹੈ? ਉਹੀ ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ - ਪ੍ਰੋਫਾਈਲ ਦ੍ਰਿਸ਼?

ਇੱਕ ਲਾਜ਼ੀਕਲ ਸਵਾਲ ਵੱਧ. ਨਹੀਂ - ਇਹ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਨਹੀਂ ਹੈ, ਹਾਲਾਂਕਿ ਇਹ ਇਸ ਤੋਂ ਬਿਨਾਂ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ। ਆਓ ਦੋ ਪਰਿਭਾਸ਼ਾਵਾਂ ਨੂੰ ਵੇਖੀਏ:

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

ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ - ਇਹ ਇੱਕ ਭੌਤਿਕ ਹਸਤੀ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸਰਵਰ) ਨੂੰ ਕਈ ਵਰਚੁਅਲ ਵਿੱਚ ਵੰਡਣ ਦੀ ਸਮਰੱਥਾ ਹੈ, ਜਿਸ ਨਾਲ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਵਿੱਚ ਵਾਧਾ ਹੁੰਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਡੇ ਕੋਲ 3 ਸਰਵਰ 25-30 ਪ੍ਰਤੀਸ਼ਤ ਲੋਡ ਹੋਏ ਸਨ, ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਤੁਹਾਨੂੰ 1 ਸਰਵਰ ਲੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। 80-90 ਪ੍ਰਤੀਸ਼ਤ) ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਕੁਝ ਸਰੋਤਾਂ ਨੂੰ ਖਾ ਜਾਂਦੀ ਹੈ - ਤੁਹਾਨੂੰ ਹਾਈਪਰਵਾਈਜ਼ਰ ਨੂੰ ਫੀਡ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ, ਹਾਲਾਂਕਿ, ਜਿਵੇਂ ਕਿ ਅਭਿਆਸ ਨੇ ਦਿਖਾਇਆ ਹੈ, ਗੇਮ ਮੋਮਬੱਤੀ ਦੀ ਕੀਮਤ ਹੈ. ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਦਾ ਇੱਕ ਆਦਰਸ਼ ਉਦਾਹਰਨ VMWare ਹੈ, ਜੋ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਤਿਆਰ ਕਰਦਾ ਹੈ, ਜਾਂ ਉਦਾਹਰਨ ਲਈ KVM, ਜਿਸਨੂੰ ਮੈਂ ਤਰਜੀਹ ਦਿੰਦਾ ਹਾਂ, ਪਰ ਇਹ ਸੁਆਦ ਦਾ ਮਾਮਲਾ ਹੈ।

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

ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜਿਸ ਉੱਤੇ ਕਲਾਉਡ ਬਣਾਇਆ ਗਿਆ ਹੈ।

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

ਪਰ ਮੈਂ ਸਮਝਦਾ ਹਾਂ ਕਿ ਉੱਪਰ ਪੇਸ਼ ਕੀਤੀ ਗਈ ਪਰਿਭਾਸ਼ਾ ਤੋਂ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਬੱਦਲ ਕੀ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇਸ ਲਈ, NIST (ਨੈਸ਼ਨਲ ਇੰਸਟੀਚਿਊਟ ਆਫ਼ ਸਟੈਂਡਰਡਜ਼ ਐਂਡ ਟੈਕਨਾਲੋਜੀ) ਦਾ ਇੱਕ ਦਸਤਾਵੇਜ਼ 5 ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਇੱਕ ਕਲਾਉਡ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:

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

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

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

ਵੱਖ-ਵੱਖ ਸਥਿਤੀਆਂ ਲਈ ਤੁਰੰਤ ਅਨੁਕੂਲਤਾ. ਸੇਵਾਵਾਂ ਲਚਕਦਾਰ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ - ਸਰੋਤਾਂ ਦੀ ਤੇਜ਼ ਵਿਵਸਥਾ, ਉਹਨਾਂ ਦੀ ਮੁੜ ਵੰਡ, ਗਾਹਕ ਦੀ ਬੇਨਤੀ 'ਤੇ ਸਰੋਤਾਂ ਨੂੰ ਜੋੜਨਾ ਜਾਂ ਘਟਾਉਣਾ, ਅਤੇ ਗਾਹਕ ਦੇ ਹਿੱਸੇ 'ਤੇ ਇਹ ਭਾਵਨਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਕਲਾਉਡ ਸਰੋਤ ਬੇਅੰਤ ਹਨ। ਸਮਝਣ ਦੀ ਸੌਖ ਲਈ, ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਕੋਈ ਚੇਤਾਵਨੀ ਨਹੀਂ ਵੇਖਦੇ ਹੋ ਕਿ Apple iCloud ਵਿੱਚ ਤੁਹਾਡੀ ਡਿਸਕ ਸਪੇਸ ਦਾ ਹਿੱਸਾ ਗਾਇਬ ਹੋ ਗਿਆ ਹੈ ਕਿਉਂਕਿ ਸਰਵਰ 'ਤੇ ਹਾਰਡ ਡਰਾਈਵ ਟੁੱਟ ਗਈ ਹੈ, ਅਤੇ ਡਰਾਈਵਾਂ ਟੁੱਟ ਗਈਆਂ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਤੁਹਾਡੇ ਹਿੱਸੇ 'ਤੇ, ਇਸ ਸੇਵਾ ਦੀਆਂ ਸੰਭਾਵਨਾਵਾਂ ਲਗਭਗ ਬੇਅੰਤ ਹਨ - ਤੁਹਾਨੂੰ 2 ਟੀਬੀ ਦੀ ਜ਼ਰੂਰਤ ਹੈ - ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ, ਤੁਸੀਂ ਭੁਗਤਾਨ ਕੀਤਾ ਅਤੇ ਪ੍ਰਾਪਤ ਕੀਤਾ। ਇਸੇ ਤਰ੍ਹਾਂ ਦੀ ਉਦਾਹਰਣ Google.Drive ਜਾਂ Yandex.Disk ਨਾਲ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ।

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

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

ਸਾਨੂੰ ਇੱਕ ਬੱਦਲ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?

ਹਾਲਾਂਕਿ, ਕੋਈ ਵੀ ਨਵੀਂ ਜਾਂ ਮੌਜੂਦਾ ਤਕਨਾਲੋਜੀ, ਕੋਈ ਵੀ ਨਵਾਂ ਪ੍ਰੋਟੋਕੋਲ ਕਿਸੇ ਚੀਜ਼ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ (ਠੀਕ ਹੈ, RIP-ng ਨੂੰ ਛੱਡ ਕੇ, ਬੇਸ਼ਕ). ਕਿਸੇ ਨੂੰ ਵੀ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਖ਼ਾਤਰ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਜ਼ਰੂਰਤ ਹੈ (ਠੀਕ ਹੈ, RIP-ng ਨੂੰ ਛੱਡ ਕੇ, ਬੇਸ਼ਕ)। ਇਹ ਤਰਕਪੂਰਨ ਹੈ ਕਿ ਕਲਾਉਡ ਉਪਭੋਗਤਾ/ਕਲਾਇੰਟ ਨੂੰ ਕਿਸੇ ਕਿਸਮ ਦੀ ਸੇਵਾ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਅਸੀਂ ਸਾਰੇ ਘੱਟੋ-ਘੱਟ ਕੁਝ ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਤੋਂ ਜਾਣੂ ਹਾਂ, ਉਦਾਹਰਨ ਲਈ Dropbox ਜਾਂ Google.Docs, ਅਤੇ ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ ਜ਼ਿਆਦਾਤਰ ਲੋਕ ਇਹਨਾਂ ਦੀ ਸਫਲਤਾਪੂਰਵਕ ਵਰਤੋਂ ਕਰਦੇ ਹਨ - ਉਦਾਹਰਨ ਲਈ, ਇਹ ਲੇਖ Google.Docs ਕਲਾਉਡ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਿਖਿਆ ਗਿਆ ਸੀ। ਪਰ ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਜੋ ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਉਹ ਕਲਾਉਡ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਦਾ ਹੀ ਹਿੱਸਾ ਹਨ — ਵਧੇਰੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ, ਉਹ ਸਿਰਫ ਇੱਕ SaaS- ਕਿਸਮ ਦੀ ਸੇਵਾ ਹਨ। ਅਸੀਂ ਤਿੰਨ ਤਰੀਕਿਆਂ ਨਾਲ ਕਲਾਉਡ ਸੇਵਾ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹਾਂ: SaaS, PaaS ਜਾਂ IaaS ਦੇ ਰੂਪ ਵਿੱਚ। ਤੁਹਾਨੂੰ ਕਿਹੜੀ ਸੇਵਾ ਦੀ ਲੋੜ ਹੈ ਇਹ ਤੁਹਾਡੀਆਂ ਇੱਛਾਵਾਂ ਅਤੇ ਸਮਰੱਥਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

ਆਉ ਹਰ ਇੱਕ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਵੇਖੀਏ:

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

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

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

ਓਪਨਸਟੈਕ ਕੀ ਹੈ?

ਸਾਰੇ ਤਿੰਨ ਵਿਕਲਪਾਂ ਵਿੱਚ, ਸੇਵਾ ਪ੍ਰਦਾਤਾ ਨੂੰ ਇੱਕ OS ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਕਲਾਉਡ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਬਣਾਉਣ ਦੇ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, SaaS ਦੇ ਨਾਲ, ਇੱਕ ਤੋਂ ਵੱਧ ਡਿਵੀਜ਼ਨ ਟੈਕਨਾਲੋਜੀ ਦੇ ਪੂਰੇ ਸਟੈਕ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ - ਇੱਕ ਡਿਵੀਜ਼ਨ ਹੈ ਜੋ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ - ਅਰਥਾਤ, ਇਹ ਕਿਸੇ ਹੋਰ ਡਿਵੀਜ਼ਨ ਨੂੰ IaaS ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਇਹ ਡਿਵੀਜ਼ਨ ਗਾਹਕ ਨੂੰ SaaS ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਓਪਨਸਟੈਕ ਕਲਾਉਡ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਇੱਕ ਸਿੰਗਲ ਸਰੋਤ ਪੂਲ ਵਿੱਚ ਸਵਿੱਚਾਂ, ਸਰਵਰਾਂ ਅਤੇ ਸਟੋਰੇਜ ਪ੍ਰਣਾਲੀਆਂ ਦਾ ਇੱਕ ਸਮੂਹ ਇਕੱਠਾ ਕਰਨ, ਇਸ ਸਾਂਝੇ ਪੂਲ ਨੂੰ ਸਬਪੂਲ (ਕਿਰਾਏਦਾਰਾਂ) ਵਿੱਚ ਵੰਡਣ ਅਤੇ ਨੈੱਟਵਰਕ ਉੱਤੇ ਗਾਹਕਾਂ ਨੂੰ ਇਹ ਸਰੋਤ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।

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

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

ਇਸ ਸਮੱਗਰੀ ਨੂੰ ਲਿਖਣ ਦੇ ਸਮੇਂ, ਓਪਨਸਟੈਕ ਬਣਤਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

ਤੋਂ ਲਈ ਗਈ ਤਸਵੀਰ openstack.org

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

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

ਸਾਰੇ ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਪੂਰੀ ਸੂਚੀ ਅਤੇ ਉਹਨਾਂ ਦੇ ਉਦੇਸ਼ ਨੂੰ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਇੱਥੇ.

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

ਹਾਲਾਂਕਿ, ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਓਪਨਸਟੈਕ ਵਿੱਚ ਚੱਲ ਰਹੀਆਂ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਆਖਰਕਾਰ ਨੈਟਵਰਕ ਨਾਲ ਜੁੜੀਆਂ ਕਿਸੇ ਕਿਸਮ ਦੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ (ਜਾਂ ਕੰਟੇਨਰ) ਹਨ। ਸਵਾਲ ਉੱਠਦਾ ਹੈ - ਸਾਨੂੰ ਇੰਨੇ ਸਾਰੇ ਤੱਤਾਂ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?

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

1. ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਮਸ਼ੀਨ ਬਣਾਉਣ ਲਈ ਇੱਕ ਬੇਨਤੀ ਬਣਾਉਂਦੇ ਹੋ, ਭਾਵੇਂ ਇਹ ਹੋਰੀਜ਼ਨ (ਡੈਸ਼ਬੋਰਡ) ਦੁਆਰਾ ਬੇਨਤੀ ਹੋਵੇ ਜਾਂ CLI ਦੁਆਰਾ ਇੱਕ ਬੇਨਤੀ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਵਾਪਰਦਾ ਹੈ ਉਹ ਕੀਸਟੋਨ 'ਤੇ ਤੁਹਾਡੀ ਬੇਨਤੀ ਦਾ ਅਧਿਕਾਰ ਹੈ - ਕੀ ਤੁਸੀਂ ਇੱਕ ਮਸ਼ੀਨ ਬਣਾ ਸਕਦੇ ਹੋ, ਕੀ ਇਸ ਕੋਲ ਹੈ? ਇਸ ਨੈੱਟਵਰਕ ਨੂੰ ਵਰਤਣ ਦਾ ਅਧਿਕਾਰ, ਕੀ ਤੁਹਾਡਾ ਡਰਾਫਟ ਕੋਟਾ, ਆਦਿ।
2. ਕੀਸਟੋਨ ਤੁਹਾਡੀ ਬੇਨਤੀ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਸੰਦੇਸ਼ ਵਿੱਚ ਇੱਕ ਪ੍ਰਮਾਣਿਕਤਾ ਟੋਕਨ ਬਣਾਉਂਦਾ ਹੈ, ਜੋ ਅੱਗੇ ਵਰਤਿਆ ਜਾਵੇਗਾ। ਕੀਸਟੋਨ ਤੋਂ ਜਵਾਬ ਪ੍ਰਾਪਤ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਬੇਨਤੀ ਨੋਵਾ (ਨੋਵਾ ਏਪੀਆਈ) ਵੱਲ ਭੇਜੀ ਜਾਂਦੀ ਹੈ।
3. Nova-api ਪਹਿਲਾਂ ਤਿਆਰ ਕੀਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਟੋਕਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਸਟੋਨ ਨਾਲ ਸੰਪਰਕ ਕਰਕੇ ਤੁਹਾਡੀ ਬੇਨਤੀ ਦੀ ਵੈਧਤਾ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ
4. ਕੀਸਟੋਨ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਪ੍ਰਮਾਣਿਕਤਾ ਟੋਕਨ ਦੇ ਅਧਾਰ ਤੇ ਅਨੁਮਤੀਆਂ ਅਤੇ ਪਾਬੰਦੀਆਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
5. Nova-api ਨੋਵਾ-ਡਾਟਾਬੇਸ ਵਿੱਚ ਨਵੇਂ VM ਲਈ ਇੱਕ ਐਂਟਰੀ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਮਸ਼ੀਨ ਨੂੰ ਨੋਵਾ-ਸ਼ਡਿਊਲਰ ਨੂੰ ਬਣਾਉਣ ਦੀ ਬੇਨਤੀ ਨੂੰ ਪਾਸ ਕਰਦਾ ਹੈ।
6. ਨੋਵਾ-ਸ਼ਡਿਊਲਰ ਹੋਸਟ (ਕੰਪਿਊਟਰ ਨੋਡ) ਦੀ ਚੋਣ ਕਰਦਾ ਹੈ ਜਿਸ 'ਤੇ VM ਨੂੰ ਨਿਰਧਾਰਤ ਮਾਪਦੰਡਾਂ, ਵਜ਼ਨ ਅਤੇ ਜ਼ੋਨਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਤੈਨਾਤ ਕੀਤਾ ਜਾਵੇਗਾ। ਇਸ ਦਾ ਰਿਕਾਰਡ ਅਤੇ VM ID ਨੂੰ ਨੋਵਾ-ਡਾਟਾਬੇਸ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ।
7. ਅੱਗੇ, ਨੋਵਾ-ਸ਼ਡਿਊਲਰ ਨੋਵਾ-ਕੰਪਿਊਟ ਨੂੰ ਇੱਕ ਉਦਾਹਰਨ ਤੈਨਾਤ ਕਰਨ ਦੀ ਬੇਨਤੀ ਨਾਲ ਸੰਪਰਕ ਕਰਦਾ ਹੈ। ਮਸ਼ੀਨ ਪੈਰਾਮੀਟਰਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਨੋਵਾ-ਕੰਪਿਊਟ ਸੰਪਰਕ ਨੋਵਾ-ਕੰਡਕਟਰ (ਨੋਵਾ-ਕੰਡਕਟਰ ਇੱਕ ਨੋਵਾ ਤੱਤ ਹੈ ਜੋ ਨੋਵਾ-ਡਾਟਾਬੇਸ ਅਤੇ ਨੋਵਾ-ਕੰਪਿਊਟ ਵਿਚਕਾਰ ਇੱਕ ਪ੍ਰੌਕਸੀ ਸਰਵਰ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਡਾਟਾਬੇਸ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚਣ ਲਈ ਨੋਵਾ-ਡਾਟਾਬੇਸ ਲਈ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ। ਇਕਸਾਰਤਾ ਲੋਡ ਕਮੀ)।
8. ਨੋਵਾ-ਕੰਡਕਟਰ ਨੋਵਾ-ਡਾਟਾਬੇਸ ਤੋਂ ਬੇਨਤੀ ਕੀਤੀ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਨੋਵਾ-ਕੰਪਿਊਟ ਨੂੰ ਭੇਜਦਾ ਹੈ।
9. ਅੱਗੇ, ਚਿੱਤਰ ID ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਨੋਵਾ-ਕੰਪਿਊਟ ਕਾਲਾਂ ਦੀ ਝਲਕ। Glace ਕੀਸਟੋਨ ਵਿੱਚ ਬੇਨਤੀ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਬੇਨਤੀ ਕੀਤੀ ਜਾਣਕਾਰੀ ਨੂੰ ਵਾਪਸ ਕਰਦਾ ਹੈ।
10. ਨੈੱਟਵਰਕ ਪੈਰਾਮੀਟਰਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਨੋਵਾ-ਕੰਪਿਊਟ ਸੰਪਰਕ ਨਿਊਟ੍ਰੋਨ। ਝਲਕ ਦੇ ਸਮਾਨ, ਨਿਊਟ੍ਰੋਨ ਕੀਸਟੋਨ ਵਿੱਚ ਬੇਨਤੀ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਇਹ ਡੇਟਾਬੇਸ (ਪੋਰਟ ਪਛਾਣਕਰਤਾ, ਆਦਿ) ਵਿੱਚ ਇੱਕ ਐਂਟਰੀ ਬਣਾਉਂਦਾ ਹੈ, ਇੱਕ ਪੋਰਟ ਬਣਾਉਣ ਲਈ ਇੱਕ ਬੇਨਤੀ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਬੇਨਤੀ ਕੀਤੀ ਜਾਣਕਾਰੀ ਨੂੰ ਨੋਵਾ-ਕੰਪਿਊਟ ਵਿੱਚ ਵਾਪਸ ਕਰਦਾ ਹੈ।
11. ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨੂੰ ਵਾਲੀਅਮ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਬੇਨਤੀ ਦੇ ਨਾਲ ਨੋਵਾ-ਕੰਪਿਊਟ ਸੰਪਰਕ ਸਿੰਡਰ। ਝਲਕ ਦੇ ਸਮਾਨ, ਸਾਈਡਰ ਕੀਸਟੋਨ ਵਿੱਚ ਬੇਨਤੀ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਇੱਕ ਵਾਲੀਅਮ ਬਣਾਉਣ ਦੀ ਬੇਨਤੀ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਬੇਨਤੀ ਕੀਤੀ ਜਾਣਕਾਰੀ ਵਾਪਸ ਕਰਦਾ ਹੈ।
12. ਨੋਵਾ-ਕੰਪਿਊਟ ਸੰਪਰਕ libvirt ਨੂੰ ਦਿੱਤੇ ਪੈਰਾਮੀਟਰਾਂ ਨਾਲ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨੂੰ ਤਾਇਨਾਤ ਕਰਨ ਦੀ ਬੇਨਤੀ ਨਾਲ।

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

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

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

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

ਇਸ ਲਈ ਸਾਡੇ ਕੋਲ ਦੋ RED ਕਲਾਇੰਟ VM ਅਤੇ ਦੋ GREEN ਕਲਾਇੰਟ VM ਹਨ। ਮੰਨ ਲਓ ਕਿ ਇਹ ਮਸ਼ੀਨਾਂ ਦੋ ਹਾਈਪਰਵਾਈਜ਼ਰਾਂ 'ਤੇ ਇਸ ਤਰੀਕੇ ਨਾਲ ਸਥਿਤ ਹਨ:

ਇਸ ਸਮੇਂ, ਇਹ ਸਿਰਫ਼ 4 ਸਰਵਰਾਂ ਦਾ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ, ਕਿਉਂਕਿ ਹੁਣ ਤੱਕ ਅਸੀਂ 4 ਸਰਵਰਾਂ ਨੂੰ ਦੋ ਭੌਤਿਕ ਸਰਵਰਾਂ 'ਤੇ ਰੱਖ ਕੇ ਵਰਚੁਅਲਾਈਜ਼ ਕੀਤਾ ਹੈ। ਅਤੇ ਹੁਣ ਤੱਕ ਉਹ ਨੈੱਟਵਰਕ ਨਾਲ ਜੁੜੇ ਵੀ ਨਹੀਂ ਹਨ।

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

ਸਾਨੂੰ ਕਿਤੇ VTEP ਲੱਭਣ ਦੀ ਲੋੜ ਹੈ (ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਹਰ ਕੋਈ VxLAN ਸ਼ਬਦਾਵਲੀ ਤੋਂ ਜਾਣੂ ਹੈ)। ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਇੱਕ L3 ਨੈੱਟਵਰਕ ਹੈ ਜੋ ਸਰਵਰਾਂ ਤੋਂ ਸਿੱਧਾ ਆ ਰਿਹਾ ਹੈ, ਸਾਨੂੰ ਸਰਵਰਾਂ 'ਤੇ VTEP ਰੱਖਣ ਤੋਂ ਕੁਝ ਵੀ ਨਹੀਂ ਰੋਕਦਾ, ਅਤੇ OVS (OpenvSwitch) ਅਜਿਹਾ ਕਰਨ ਵਿੱਚ ਵਧੀਆ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਸਾਨੂੰ ਇਹ ਡਿਜ਼ਾਈਨ ਮਿਲਿਆ ਹੈ:

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

ਹੁਣ ਅਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਉਹਨਾਂ ਲਈ ਆਪਣੀਆਂ ਮਸ਼ੀਨਾਂ ਅਤੇ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਬਣਾ ਸਕਦੇ ਹਾਂ।

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

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

ਭਾਵ, ਸਾਨੂੰ ਹੇਠ ਲਿਖਿਆ ਚਿੱਤਰ ਮਿਲਦਾ ਹੈ:

L2 ਸੁਰੰਗਾਂ ਸਾਰੇ ਕੰਪਿਊਟਿੰਗ ਨੋਡਾਂ ਤੋਂ ਕੰਟਰੋਲ ਨੋਡ ਤੱਕ ਪਹੁੰਚਦੀਆਂ ਹਨ। ਨੋਡ ਜਿੱਥੇ ਇਹਨਾਂ ਨੈੱਟਵਰਕਾਂ ਲਈ L3 ਇੰਟਰਫੇਸ ਸਥਿਤ ਹੈ, ਹਰੇਕ ਆਈਸੋਲੇਸ਼ਨ ਲਈ ਇੱਕ ਸਮਰਪਿਤ ਨੇਮਸਪੇਸ ਵਿੱਚ।

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

ਨਤੀਜੇ ਵਜੋਂ, ਸਾਨੂੰ ਇਹ ਚਿੱਤਰ ਮਿਲਿਆ:

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

ਅਸਲ ਵਿੱਚ, ਸਾਡੀ ਸਕੀਮ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰਨ ਯੋਗ ਹੈ, ਪਰ ਇੱਥੇ ਕੁਝ ਸੂਖਮਤਾਵਾਂ ਹਨ:

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

ਆਉ ਮਸ਼ੀਨ ਸੁਰੱਖਿਆ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ. ਇਸਦੇ ਲਈ ਤੁਸੀਂ ਬੈਨਲ iptables ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਕਿਉਂ ਨਹੀਂ।

ਭਾਵ, ਹੁਣ ਸਾਡੀ ਟੌਪੋਲੋਜੀ ਥੋੜੀ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੋ ਗਈ ਹੈ:

ਆਓ ਅੱਗੇ ਵਧੀਏ। ਸਾਨੂੰ ਇੱਕ DHCP ਸਰਵਰ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ। ਹਰੇਕ ਕਲਾਇੰਟ ਲਈ DHCP ਸਰਵਰਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਸਭ ਤੋਂ ਆਦਰਸ਼ ਸਥਾਨ ਪਹਿਲਾਂ ਹੀ ਉੱਪਰ ਜ਼ਿਕਰ ਕੀਤਾ ਕੰਟਰੋਲ ਨੋਡ ਹੋਵੇਗਾ, ਜਿੱਥੇ ਨੇਮਸਪੇਸ ਸਥਿਤ ਹਨ:

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

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

ਅਤੇ ਇੱਥੇ NAT ਸਾਡੀ ਮਦਦ ਲਈ ਆਉਂਦਾ ਹੈ - ਅਸੀਂ ਸਿਰਫ਼ NAT ਅਨੁਵਾਦ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਗਾਹਕਾਂ ਲਈ ਡਿਫੌਲਟ ਨੇਮਸਪੇਸ ਰਾਹੀਂ ਬਾਹਰੀ ਸੰਸਾਰ ਤੱਕ ਪਹੁੰਚ ਕਰਨਾ ਸੰਭਵ ਬਣਾਵਾਂਗੇ। ਖੈਰ, ਇੱਥੇ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਸਮੱਸਿਆ ਹੈ। ਇਹ ਚੰਗਾ ਹੈ ਜੇਕਰ ਕਲਾਇੰਟ ਸਰਵਰ ਇੱਕ ਕਲਾਇੰਟ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਨਾ ਕਿ ਇੱਕ ਸਰਵਰ ਦੇ ਤੌਰ ਤੇ - ਭਾਵ, ਇਹ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਦੀ ਬਜਾਏ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਪਰ ਸਾਡੇ ਲਈ ਇਹ ਬਿਲਕੁਲ ਉਲਟ ਹੋਵੇਗਾ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਾਨੂੰ ਡੈਸਟੀਨੇਸ਼ਨ NAT ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਜੋ ਟ੍ਰੈਫਿਕ ਪ੍ਰਾਪਤ ਕਰਨ ਵੇਲੇ, ਕੰਟਰੋਲ ਨੋਡ ਸਮਝੇ ਕਿ ਇਹ ਟ੍ਰੈਫਿਕ ਕਲਾਇੰਟ A ਦੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ A ਲਈ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਨੂੰ ਇੱਕ ਬਾਹਰੀ ਪਤੇ ਤੋਂ NAT ਅਨੁਵਾਦ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਉਦਾਹਰਨ ਲਈ 100.1.1.1 .10.0.0.1, ਇੱਕ ਅੰਦਰੂਨੀ ਪਤੇ 100 ਲਈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਹਾਲਾਂਕਿ ਸਾਰੇ ਗਾਹਕ ਇੱਕੋ ਨੈਟਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰਨਗੇ, ਅੰਦਰੂਨੀ ਅਲੱਗ-ਥਲੱਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਰੱਖਿਅਤ ਹੈ। ਭਾਵ, ਸਾਨੂੰ ਕੰਟਰੋਲ ਨੋਡ 'ਤੇ dNAT ਅਤੇ sNAT ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਫਲੋਟਿੰਗ ਪਤਿਆਂ ਜਾਂ ਬਾਹਰੀ ਨੈੱਟਵਰਕਾਂ ਜਾਂ ਦੋਵਾਂ ਨਾਲ ਇੱਕੋ ਨੈੱਟਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਲਾਉਡ ਵਿੱਚ ਕੀ ਲਿਆਉਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਅਸੀਂ ਡਾਇਗ੍ਰਾਮ ਵਿੱਚ ਫਲੋਟਿੰਗ ਐਡਰੈੱਸ ਨਹੀਂ ਜੋੜਾਂਗੇ, ਪਰ ਪਹਿਲਾਂ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਬਾਹਰੀ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਛੱਡ ਦੇਵਾਂਗੇ - ਹਰੇਕ ਕਲਾਇੰਟ ਦਾ ਆਪਣਾ ਬਾਹਰੀ ਨੈੱਟਵਰਕ ਹੁੰਦਾ ਹੈ (ਡਾਇਗਰਾਮ ਵਿੱਚ ਉਹ ਬਾਹਰੀ ਇੰਟਰਫੇਸ 'ਤੇ vlan 200 ਅਤੇ XNUMX ਵਜੋਂ ਦਰਸਾਏ ਗਏ ਹਨ)।

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

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

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

ਅਗਲੀ ਸਮੱਸਿਆ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਡਿਸਕਾਂ ਦੀ ਹੈ। ਇਸ ਸਮੇਂ, ਉਹ ਆਪਣੇ ਆਪ ਹਾਈਪਰਵਾਈਜ਼ਰਾਂ 'ਤੇ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਹਾਈਪਰਵਾਈਜ਼ਰ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਦੀ ਸਥਿਤੀ ਵਿੱਚ, ਅਸੀਂ ਸਾਰਾ ਡੇਟਾ ਗੁਆ ਦਿੰਦੇ ਹਾਂ - ਅਤੇ ਇੱਕ ਛਾਪੇ ਦੀ ਮੌਜੂਦਗੀ ਇੱਥੇ ਮਦਦ ਨਹੀਂ ਕਰੇਗੀ ਜੇਕਰ ਅਸੀਂ ਡਿਸਕ ਨਹੀਂ, ਬਲਕਿ ਪੂਰਾ ਸਰਵਰ ਗੁਆ ਦਿੰਦੇ ਹਾਂ. ਅਜਿਹਾ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਇੱਕ ਸੇਵਾ ਬਣਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਜੋ ਕਿਸੇ ਕਿਸਮ ਦੀ ਸਟੋਰੇਜ ਲਈ ਫਰੰਟ ਐਂਡ ਦੇ ਤੌਰ ਤੇ ਕੰਮ ਕਰੇਗੀ. ਇਹ ਕਿਹੋ ਜਿਹੀ ਸਟੋਰੇਜ ਹੋਵੇਗੀ ਇਹ ਸਾਡੇ ਲਈ ਖਾਸ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ, ਪਰ ਇਸ ਨੂੰ ਸਾਡੇ ਡੇਟਾ ਨੂੰ ਡਿਸਕ ਅਤੇ ਨੋਡ, ਅਤੇ ਸੰਭਵ ਤੌਰ 'ਤੇ ਪੂਰੀ ਕੈਬਨਿਟ ਦੀ ਅਸਫਲਤਾ ਤੋਂ ਬਚਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਵਿਕਲਪ ਹਨ - ਬੇਸ਼ੱਕ, ਫਾਈਬਰ ਚੈਨਲ ਦੇ ਨਾਲ SAN ਨੈਟਵਰਕ ਹਨ, ਪਰ ਆਓ ਇਮਾਨਦਾਰ ਬਣੀਏ - FC ਪਹਿਲਾਂ ਹੀ ਅਤੀਤ ਦੀ ਯਾਦ ਹੈ - ਆਵਾਜਾਈ ਵਿੱਚ E1 ਦਾ ਇੱਕ ਐਨਾਲਾਗ - ਹਾਂ, ਮੈਂ ਸਹਿਮਤ ਹਾਂ, ਇਹ ਅਜੇ ਵੀ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਸਿਰਫ ਜਿੱਥੇ ਇਹ ਇਸ ਤੋਂ ਬਿਨਾਂ ਬਿਲਕੁਲ ਅਸੰਭਵ ਹੈ. ਇਸ ਲਈ, ਮੈਂ ਆਪਣੀ ਮਰਜ਼ੀ ਨਾਲ 2020 ਵਿੱਚ ਇੱਕ FC ਨੈੱਟਵਰਕ ਨੂੰ ਤੈਨਾਤ ਨਹੀਂ ਕਰਾਂਗਾ, ਇਹ ਜਾਣਦੇ ਹੋਏ ਕਿ ਹੋਰ ਵੀ ਦਿਲਚਸਪ ਵਿਕਲਪ ਹਨ। ਹਾਲਾਂਕਿ ਹਰ ਇੱਕ ਲਈ ਉਸਦਾ ਆਪਣਾ, ਇੱਥੇ ਉਹ ਲੋਕ ਹੋ ਸਕਦੇ ਹਨ ਜੋ ਮੰਨਦੇ ਹਨ ਕਿ FC ਦੀਆਂ ਸਾਰੀਆਂ ਸੀਮਾਵਾਂ ਦੇ ਨਾਲ ਸਾਨੂੰ ਸਭ ਦੀ ਜ਼ਰੂਰਤ ਹੈ - ਮੈਂ ਬਹਿਸ ਨਹੀਂ ਕਰਾਂਗਾ, ਹਰ ਇੱਕ ਦੀ ਆਪਣੀ ਰਾਏ ਹੈ. ਹਾਲਾਂਕਿ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਹੱਲ ਇੱਕ SDS ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ, ਜਿਵੇਂ ਕਿ Ceph.

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

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

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

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

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

ਨਿਊਟ੍ਰੋਨ ਆਰਕੀਟੈਕਚਰ

ਓਪਨਸਟੈਕ ਵਿੱਚ, ਇਹ ਨਿਊਟ੍ਰੋਨ ਹੈ ਜੋ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਪੋਰਟਾਂ ਨੂੰ ਇੱਕ ਆਮ L2 ਨੈੱਟਵਰਕ ਨਾਲ ਜੋੜਨ, ਵੱਖ-ਵੱਖ L2 ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਸਥਿਤ VMs ਵਿਚਕਾਰ ਟਰੈਫ਼ਿਕ ਰੂਟਿੰਗ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਦੇ ਨਾਲ-ਨਾਲ ਬਾਹਰੀ ਰੂਟਿੰਗ, NAT, ਫਲੋਟਿੰਗ IP, DHCP, ਆਦਿ ਵਰਗੀਆਂ ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ।

ਇੱਕ ਉੱਚ ਪੱਧਰ 'ਤੇ, ਨੈੱਟਵਰਕ ਸੇਵਾ ਦੇ ਸੰਚਾਲਨ (ਮੁਢਲੇ ਹਿੱਸੇ) ਨੂੰ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਵਰਣਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ.

VM ਸ਼ੁਰੂ ਕਰਨ ਵੇਲੇ, ਨੈੱਟਵਰਕ ਸੇਵਾ:

1. ਦਿੱਤੇ ਗਏ VM (ਜਾਂ ਪੋਰਟਾਂ) ਲਈ ਇੱਕ ਪੋਰਟ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਇਸ ਬਾਰੇ DHCP ਸੇਵਾ ਨੂੰ ਸੂਚਿਤ ਕਰਦਾ ਹੈ;
2. ਇੱਕ ਨਵਾਂ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਜੰਤਰ ਬਣਾਇਆ ਗਿਆ ਹੈ (libvirt ਰਾਹੀਂ);
3. VM ਕਦਮ 1 ਵਿੱਚ ਬਣਾਏ ਗਏ ਪੋਰਟ (ਪੋਰਟਾਂ) ਨਾਲ ਜੁੜਦਾ ਹੈ;

ਅਜੀਬ ਤੌਰ 'ਤੇ, ਨਿਊਟ੍ਰੋਨ ਦਾ ਕੰਮ ਮਿਆਰੀ ਵਿਧੀਆਂ 'ਤੇ ਅਧਾਰਤ ਹੈ ਜੋ ਹਰ ਕਿਸੇ ਲਈ ਜਾਣੂ ਹੈ ਜਿਸ ਨੇ ਕਦੇ ਵੀ ਲੀਨਕਸ - ਨੇਮਸਪੇਸ, iptables, ਲੀਨਕਸ ਬ੍ਰਿਜ, ਓਪਨਵਸਵਿਚ, ਕੰਟਰੈਕ, ਆਦਿ ਵਿੱਚ ਡੁਬਕੀ ਲਗਾਈ ਹੈ।

ਇਹ ਤੁਰੰਤ ਸਪੱਸ਼ਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਨਿਊਟ੍ਰੋਨ ਇੱਕ SDN ਕੰਟਰੋਲਰ ਨਹੀਂ ਹੈ।

ਨਿਊਟ੍ਰੋਨ ਵਿੱਚ ਕਈ ਆਪਸ ਵਿੱਚ ਜੁੜੇ ਹੋਏ ਹਿੱਸੇ ਹੁੰਦੇ ਹਨ:

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

ਨਿਊਟ੍ਰੋਨ-ਸਰਵਰ ਅਸਲ ਵਿੱਚ ਪਾਈਥਨ ਵਿੱਚ ਲਿਖੀ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਹੈ, ਜਿਸ ਵਿੱਚ ਦੋ ਭਾਗ ਹਨ:

• REST ਸੇਵਾ
• ਨਿਊਟ੍ਰੋਨ ਪਲੱਗਇਨ (ਕੋਰ/ਸੇਵਾ)

REST ਸੇਵਾ ਨੂੰ ਦੂਜੇ ਭਾਗਾਂ ਤੋਂ API ਕਾਲਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਕੁਝ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਬੇਨਤੀ, ਆਦਿ)

ਪਲੱਗਇਨ ਪਲੱਗ-ਇਨ ਸੌਫਟਵੇਅਰ ਕੰਪੋਨੈਂਟ/ਮੋਡਿਊਲ ਹੁੰਦੇ ਹਨ ਜੋ API ਬੇਨਤੀਆਂ ਦੇ ਦੌਰਾਨ ਬੁਲਾਏ ਜਾਂਦੇ ਹਨ - ਭਾਵ, ਉਹਨਾਂ ਦੁਆਰਾ ਸੇਵਾ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੁੰਦੀ ਹੈ। ਪਲੱਗਇਨ ਨੂੰ ਦੋ ਕਿਸਮਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ - ਸੇਵਾ ਅਤੇ ਰੂਟ। ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ, ਘੋੜਾ ਪਲੱਗਇਨ ਮੁੱਖ ਤੌਰ 'ਤੇ VMs ਵਿਚਕਾਰ ਐਡਰੈੱਸ ਸਪੇਸ ਅਤੇ L2 ਕਨੈਕਸ਼ਨਾਂ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ, ਅਤੇ ਸੇਵਾ ਪਲੱਗਇਨ ਪਹਿਲਾਂ ਹੀ ਵਾਧੂ ਕਾਰਜਕੁਸ਼ਲਤਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਜਿਵੇਂ ਕਿ VPN ਜਾਂ FW।

ਅੱਜ ਉਪਲਬਧ ਪਲੱਗਇਨਾਂ ਦੀ ਸੂਚੀ ਉਦਾਹਰਨ ਲਈ ਦੇਖੀ ਜਾ ਸਕਦੀ ਹੈ ਇੱਥੇ

ਇੱਥੇ ਕਈ ਸੇਵਾ ਪਲੱਗਇਨ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਸਿਰਫ ਇੱਕ ਘੋੜਾ ਪਲੱਗਇਨ ਹੋ ਸਕਦਾ ਹੈ।

openstack-neutron-ml2 ਸਟੈਂਡਰਡ ਓਪਨਸਟੈਕ ਰੂਟ ਪਲੱਗਇਨ ਹੈ। ਇਸ ਪਲੱਗਇਨ ਵਿੱਚ ਇੱਕ ਮਾਡਿਊਲਰ ਆਰਕੀਟੈਕਚਰ ਹੈ (ਇਸਦੇ ਪੂਰਵਵਰਤੀ ਦੇ ਉਲਟ) ਅਤੇ ਇਸ ਨਾਲ ਜੁੜੇ ਡਰਾਈਵਰਾਂ ਰਾਹੀਂ ਨੈੱਟਵਰਕ ਸੇਵਾ ਨੂੰ ਸੰਰਚਿਤ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਪਲੱਗਇਨ ਨੂੰ ਥੋੜੀ ਦੇਰ ਬਾਅਦ ਵੇਖਾਂਗੇ, ਕਿਉਂਕਿ ਅਸਲ ਵਿੱਚ ਇਹ ਉਹ ਲਚਕਤਾ ਦਿੰਦਾ ਹੈ ਜੋ ਓਪਨਸਟੈਕ ਦੇ ਨੈਟਵਰਕ ਹਿੱਸੇ ਵਿੱਚ ਹੈ। ਰੂਟ ਪਲੱਗਇਨ ਨੂੰ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਣ ਲਈ, ਕੰਟਰੇਲ ਨੈੱਟਵਰਕਿੰਗ ਅਜਿਹੀ ਤਬਦੀਲੀ ਕਰਦੀ ਹੈ)।

RPC ਸੇਵਾ (rabbitmq-ਸਰਵਰ) — ਇੱਕ ਸੇਵਾ ਜੋ ਕਤਾਰ ਪ੍ਰਬੰਧਨ ਅਤੇ ਹੋਰ ਓਪਨਸਟੈਕ ਸੇਵਾਵਾਂ ਦੇ ਨਾਲ ਇੰਟਰੈਕਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਨਾਲ ਹੀ ਨੈੱਟਵਰਕ ਸੇਵਾ ਏਜੰਟਾਂ ਵਿਚਕਾਰ ਆਪਸੀ ਤਾਲਮੇਲ।

ਨੈੱਟਵਰਕ ਏਜੰਟ — ਏਜੰਟ ਜੋ ਹਰੇਕ ਨੋਡ ਵਿੱਚ ਸਥਿਤ ਹਨ, ਜਿਸ ਰਾਹੀਂ ਨੈੱਟਵਰਕ ਸੇਵਾਵਾਂ ਨੂੰ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਏਜੰਟਾਂ ਦੀਆਂ ਕਈ ਕਿਸਮਾਂ ਹਨ.

ਮੁੱਖ ਏਜੰਟ ਹੈ L2 ਏਜੰਟ. ਇਹ ਏਜੰਟ ਹਰ ਇੱਕ ਹਾਈਪਰਵਾਈਜ਼ਰ 'ਤੇ ਚੱਲਦੇ ਹਨ, ਜਿਸ ਵਿੱਚ ਕੰਟਰੋਲ ਨੋਡ ਸ਼ਾਮਲ ਹਨ (ਵਧੇਰੇ ਤੌਰ 'ਤੇ, ਕਿਰਾਏਦਾਰਾਂ ਲਈ ਕੋਈ ਵੀ ਸੇਵਾ ਪ੍ਰਦਾਨ ਕਰਨ ਵਾਲੇ ਸਾਰੇ ਨੋਡਾਂ' ਤੇ) ਅਤੇ ਉਹਨਾਂ ਦਾ ਮੁੱਖ ਕੰਮ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਨੂੰ ਇੱਕ ਆਮ L2 ਨੈਟਵਰਕ ਨਾਲ ਜੋੜਨਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਕੋਈ ਵੀ ਘਟਨਾ ਵਾਪਰਦੀ ਹੈ ਤਾਂ ਚੇਤਾਵਨੀਆਂ ਵੀ ਤਿਆਰ ਕਰਦੇ ਹਨ ( ਉਦਾਹਰਨ ਲਈ ਪੋਰਟ ਨੂੰ ਅਸਮਰੱਥ/ਯੋਗ)।

ਅਗਲਾ, ਕੋਈ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਏਜੰਟ ਨਹੀਂ ਹੈ L3 ਏਜੰਟ. ਮੂਲ ਰੂਪ ਵਿੱਚ, ਇਹ ਏਜੰਟ ਸਿਰਫ਼ ਇੱਕ ਨੈੱਟਵਰਕ ਨੋਡ (ਅਕਸਰ ਨੈੱਟਵਰਕ ਨੋਡ ਨੂੰ ਇੱਕ ਕੰਟਰੋਲ ਨੋਡ ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ) 'ਤੇ ਚੱਲਦਾ ਹੈ ਅਤੇ ਕਿਰਾਏਦਾਰਾਂ ਦੇ ਨੈੱਟਵਰਕਾਂ (ਦੋਵੇਂ ਇਸਦੇ ਨੈੱਟਵਰਕਾਂ ਅਤੇ ਦੂਜੇ ਕਿਰਾਏਦਾਰਾਂ ਦੇ ਨੈੱਟਵਰਕਾਂ ਵਿਚਕਾਰ, ਅਤੇ ਬਾਹਰੀ ਦੁਨੀਆਂ ਤੱਕ ਪਹੁੰਚਯੋਗ ਹੈ) ਦੇ ਵਿਚਕਾਰ ਰੂਟਿੰਗ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। NAT, ਨਾਲ ਹੀ DHCP ਸੇਵਾ)। ਹਾਲਾਂਕਿ, ਇੱਕ DVR (ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਰਾਊਟਰ) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਇੱਕ L3 ਪਲੱਗਇਨ ਦੀ ਲੋੜ ਕੰਪਿਊਟ ਨੋਡਾਂ 'ਤੇ ਵੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ।

L3 ਏਜੰਟ ਲੀਨਕਸ ਨੇਮਸਪੇਸ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਹਰੇਕ ਕਿਰਾਏਦਾਰ ਨੂੰ ਇਸਦੇ ਆਪਣੇ ਅਲੱਗ-ਥਲੱਗ ਨੈੱਟਵਰਕਾਂ ਦੇ ਸੈੱਟ ਅਤੇ ਵਰਚੁਅਲ ਰਾਊਟਰਾਂ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਜਾ ਸਕੇ ਜੋ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੂਟ ਕਰਦੇ ਹਨ ਅਤੇ ਲੇਅਰ 2 ਨੈੱਟਵਰਕਾਂ ਲਈ ਗੇਟਵੇ ਸੇਵਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ।

ਡਾਟਾਬੇਸ — ਨੈੱਟਵਰਕ, ਸਬਨੈੱਟ, ਪੋਰਟ, ਪੂਲ, ਆਦਿ ਦੇ ਪਛਾਣਕਰਤਾਵਾਂ ਦਾ ਇੱਕ ਡੇਟਾਬੇਸ।

ਵਾਸਤਵ ਵਿੱਚ, ਨਿਊਟ੍ਰੋਨ ਕਿਸੇ ਵੀ ਨੈੱਟਵਰਕ ਇਕਾਈਆਂ ਦੇ ਨਿਰਮਾਣ ਤੋਂ API ਬੇਨਤੀਆਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਬੇਨਤੀ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ RPC (ਜੇਕਰ ਇਹ ਕੁਝ ਪਲੱਗਇਨ ਜਾਂ ਏਜੰਟ ਤੱਕ ਪਹੁੰਚ ਕਰਦਾ ਹੈ) ਜਾਂ REST API (ਜੇਕਰ ਇਹ SDN ਵਿੱਚ ਸੰਚਾਰ ਕਰਦਾ ਹੈ) ਏਜੰਟਾਂ ਨੂੰ ਸੰਚਾਰਿਤ ਕਰਦਾ ਹੈ (ਪਲੱਗਇਨ ਰਾਹੀਂ) ਬੇਨਤੀ ਕੀਤੀ ਸੇਵਾ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਹਦਾਇਤਾਂ।

ਆਉ ਹੁਣ ਟੈਸਟ ਇੰਸਟਾਲੇਸ਼ਨ ਵੱਲ ਮੁੜੀਏ (ਇਸ ਨੂੰ ਕਿਵੇਂ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਕੀ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ਵਿਹਾਰਕ ਹਿੱਸੇ ਵਿੱਚ ਦੇਖਾਂਗੇ) ਅਤੇ ਦੇਖਾਂਗੇ ਕਿ ਹਰੇਕ ਭਾਗ ਕਿੱਥੇ ਸਥਿਤ ਹੈ:

(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 

ਅਸਲ ਵਿੱਚ, ਇਹ ਨਿਊਟ੍ਰੋਨ ਦੀ ਪੂਰੀ ਬਣਤਰ ਹੈ। ਹੁਣ ਇਹ ML2 ਪਲੱਗਇਨ 'ਤੇ ਕੁਝ ਸਮਾਂ ਬਿਤਾਉਣ ਦੇ ਯੋਗ ਹੈ.

ਮਾਡਿਊਲਰ ਲੇਅਰ 2

ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਪਲੱਗਇਨ ਇੱਕ ਸਟੈਂਡਰਡ ਓਪਨਸਟੈਕ ਰੂਟ ਪਲੱਗਇਨ ਹੈ ਅਤੇ ਇਸਦਾ ਇੱਕ ਮਾਡਯੂਲਰ ਆਰਕੀਟੈਕਚਰ ਹੈ।

ML2 ਪਲੱਗਇਨ ਦੇ ਪੂਰਵਜ ਵਿੱਚ ਇੱਕ ਮੋਨੋਲੀਥਿਕ ਬਣਤਰ ਸੀ, ਜੋ ਕਿ ਇੱਕ ਇੰਸਟਾਲੇਸ਼ਨ ਵਿੱਚ ਕਈ ਤਕਨੀਕਾਂ ਦੇ ਮਿਸ਼ਰਣ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੀ ਸੀ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਇੱਕੋ ਸਮੇਂ openvswitch ਅਤੇ linuxbridge ਦੋਵਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ - ਜਾਂ ਤਾਂ ਪਹਿਲਾ ਜਾਂ ਦੂਜਾ। ਇਸ ਕਾਰਨ ਕਰਕੇ, ਇਸਦੇ ਆਰਕੀਟੈਕਚਰ ਦੇ ਨਾਲ ML2 ਪਲੱਗਇਨ ਬਣਾਇਆ ਗਿਆ ਸੀ।

ML2 ਦੇ ਦੋ ਭਾਗ ਹਨ - ਦੋ ਕਿਸਮ ਦੇ ਡਰਾਈਵਰ: ਟਾਈਪ ਡਰਾਈਵਰ ਅਤੇ ਮਕੈਨਿਜ਼ਮ ਡਰਾਈਵਰ।

ਡਰਾਈਵਰ ਟਾਈਪ ਕਰੋ ਉਹਨਾਂ ਤਕਨਾਲੋਜੀਆਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰੋ ਜੋ ਨੈਟਵਰਕ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਲਈ ਵਰਤੀਆਂ ਜਾਣਗੀਆਂ, ਉਦਾਹਰਨ ਲਈ VxLAN, VLAN, GRE। ਉਸੇ ਸਮੇਂ, ਡਰਾਈਵਰ ਵੱਖ-ਵੱਖ ਤਕਨਾਲੋਜੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ. ਮਿਆਰੀ ਤਕਨਾਲੋਜੀ ਓਵਰਲੇ ਨੈੱਟਵਰਕ ਅਤੇ vlan ਬਾਹਰੀ ਨੈੱਟਵਰਕ ਲਈ VxLAN encapsulation ਹੈ।

ਟਾਈਪ ਡਰਾਈਵਰਾਂ ਵਿੱਚ ਹੇਠ ਲਿਖੀਆਂ ਨੈੱਟਵਰਕ ਕਿਸਮਾਂ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ:

ਫਲੈਟ - ਟੈਗਿੰਗ ਤੋਂ ਬਿਨਾਂ ਨੈੱਟਵਰਕ
VLANs - ਟੈਗ ਕੀਤਾ ਨੈੱਟਵਰਕ
ਸਥਾਨਕ — ਆਲ-ਇਨ-ਵਨ ਸਥਾਪਨਾਵਾਂ ਲਈ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕਿਸਮ ਦਾ ਨੈੱਟਵਰਕ (ਅਜਿਹੀਆਂ ਸਥਾਪਨਾਵਾਂ ਜਾਂ ਤਾਂ ਡਿਵੈਲਪਰਾਂ ਜਾਂ ਸਿਖਲਾਈ ਲਈ ਲੋੜੀਂਦੇ ਹਨ)
ਜੀ.ਈ.ਆਰ. — GRE ਸੁਰੰਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਓਵਰਲੇ ਨੈੱਟਵਰਕ
VxLAN — VxLAN ਸੁਰੰਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਓਵਰਲੇ ਨੈੱਟਵਰਕ

ਮਕੈਨਿਜ਼ਮ ਡਰਾਈਵਰ ਟੂਲ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜੋ ਟਾਈਪ ਡਰਾਈਵਰ ਵਿੱਚ ਦਰਸਾਏ ਗਏ ਤਕਨਾਲੋਜੀਆਂ ਦੇ ਸੰਗਠਨ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਨ - ਉਦਾਹਰਨ ਲਈ, openvswitch, sr-iov, opendaylight, OVN, ਆਦਿ।

ਇਸ ਡ੍ਰਾਈਵਰ ਨੂੰ ਲਾਗੂ ਕਰਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਜਾਂ ਤਾਂ ਨਿਊਟ੍ਰੋਨ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਏਜੰਟਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਵੇਗੀ, ਜਾਂ ਕਿਸੇ ਬਾਹਰੀ SDN ਕੰਟਰੋਲਰ ਨਾਲ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਵੇਗੀ, ਜੋ ਕਿ L2 ਨੈੱਟਵਰਕ, ਰੂਟਿੰਗ, ਆਦਿ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਨਾਲ ਸਬੰਧਤ ਸਾਰੇ ਮੁੱਦਿਆਂ ਦਾ ਧਿਆਨ ਰੱਖਦਾ ਹੈ।

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

ਆਉ ਓਪਨ vSwitch 'ਤੇ ਬੁਰਸ਼ ਕਰੀਏ

ਇਸ ਸਮੇਂ, ਓਪਨਸਟੈਕ ਦੇ ਮੁੱਖ ਹਿੱਸਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਓਪਨ ਵੀਸਵਿਚ ਹੈ।
ਓਪਨਸਟੈਕ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਵਾਧੂ ਵਿਕਰੇਤਾ SDN ਜਿਵੇਂ ਕਿ ਜੂਨੀਪਰ ਕੰਟਰੇਲ ਜਾਂ ਨੋਕੀਆ ਨੂਏਜ ਦੇ ਸਥਾਪਤ ਕਰਨ ਵੇਲੇ, OVS ਕਲਾਉਡ ਨੈਟਵਰਕ ਦਾ ਮੁੱਖ ਨੈਟਵਰਕ ਭਾਗ ਹੈ ਅਤੇ, iptables, conntrack, ਨੇਮਸਪੇਸ ਦੇ ਨਾਲ, ਤੁਹਾਨੂੰ ਪੂਰੇ ਬਹੁ-ਕਰਾਏਦਾਰੀ ਓਵਰਲੇ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਇਸ ਹਿੱਸੇ ਨੂੰ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਤੀਜੀ-ਧਿਰ ਦੀ ਮਲਕੀਅਤ (ਵਿਕਰੇਤਾ) SDN ਹੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ।

OVS ਇੱਕ ਓਪਨ ਸੋਰਸ ਸਾਫਟਵੇਅਰ ਸਵਿੱਚ ਹੈ ਜੋ ਵਰਚੁਅਲ ਟ੍ਰੈਫਿਕ ਫਾਰਵਰਡਰ ਵਜੋਂ ਵਰਚੁਅਲਾਈਜ਼ਡ ਵਾਤਾਵਰਨ ਵਿੱਚ ਵਰਤਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ।

ਇਸ ਸਮੇਂ, OVS ਕੋਲ ਬਹੁਤ ਵਧੀਆ ਕਾਰਜਸ਼ੀਲਤਾ ਹੈ, ਜਿਸ ਵਿੱਚ QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, ਆਦਿ ਵਰਗੀਆਂ ਤਕਨਾਲੋਜੀਆਂ ਸ਼ਾਮਲ ਹਨ।

ਨੋਟ: OVS ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡ ਕੀਤੇ ਟੈਲੀਕਾਮ ਫੰਕਸ਼ਨਾਂ ਲਈ ਇੱਕ ਸਾਫਟ ਸਵਿੱਚ ਵਜੋਂ ਨਹੀਂ ਮੰਨਿਆ ਗਿਆ ਸੀ ਅਤੇ ਘੱਟ ਬੈਂਡਵਿਡਥ-ਡਿਮਾਂਡ ਕਰਨ ਵਾਲੇ IT ਫੰਕਸ਼ਨਾਂ ਜਿਵੇਂ ਕਿ WEB ਸਰਵਰ ਜਾਂ ਮੇਲ ਸਰਵਰ ਲਈ ਵਧੇਰੇ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਸੀ। ਹਾਲਾਂਕਿ, OVS ਨੂੰ ਹੋਰ ਵਿਕਸਤ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ ਅਤੇ OVS ਦੇ ਮੌਜੂਦਾ ਸਥਾਪਨ ਨੇ ਇਸਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਅਤੇ ਸਮਰੱਥਾਵਾਂ ਵਿੱਚ ਬਹੁਤ ਸੁਧਾਰ ਕੀਤਾ ਹੈ, ਜੋ ਇਸਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡ ਕੀਤੇ ਫੰਕਸ਼ਨਾਂ ਵਾਲੇ ਟੈਲੀਕਾਮ ਓਪਰੇਟਰਾਂ ਦੁਆਰਾ ਵਰਤਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, DPDK ਪ੍ਰਵੇਗ ਲਈ ਸਮਰਥਨ ਦੇ ਨਾਲ ਇੱਕ OVS ਲਾਗੂ ਕਰਨਾ ਹੈ।

OVS ਦੇ ਤਿੰਨ ਮਹੱਤਵਪੂਰਨ ਭਾਗ ਹਨ ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਤੁਹਾਨੂੰ ਸੁਚੇਤ ਹੋਣ ਦੀ ਲੋੜ ਹੈ:

• ਕਰਨਲ ਮੋਡੀਊਲ — ਕਰਨਲ ਸਪੇਸ ਵਿੱਚ ਸਥਿਤ ਇੱਕ ਕੰਪੋਨੈਂਟ ਜੋ ਕੰਟਰੋਲ ਐਲੀਮੈਂਟ ਤੋਂ ਪ੍ਰਾਪਤ ਨਿਯਮਾਂ ਦੇ ਅਧਾਰ ਤੇ ਟ੍ਰੈਫਿਕ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ;
• vSwitch ਡੈਮਨ (ovs-vswitchd) ਉਪਭੋਗਤਾ ਸਪੇਸ ਵਿੱਚ ਸ਼ੁਰੂ ਕੀਤੀ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜੋ ਕਿ ਕਰਨਲ ਮੋਡੀਊਲ ਨੂੰ ਪ੍ਰੋਗਰਾਮਿੰਗ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ - ਯਾਨੀ ਇਹ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸਵਿੱਚ ਦੀ ਕਾਰਵਾਈ ਦੇ ਤਰਕ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ।
• ਡਾਟਾਬੇਸ ਸਰਵਰ - OVS ਚਲਾਉਣ ਵਾਲੇ ਹਰੇਕ ਹੋਸਟ 'ਤੇ ਸਥਿਤ ਇੱਕ ਸਥਾਨਕ ਡਾਟਾਬੇਸ, ਜਿਸ ਵਿੱਚ ਸੰਰਚਨਾ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। SDN ਕੰਟਰੋਲਰ OVSDB ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਮੋਡੀਊਲ ਰਾਹੀਂ ਸੰਚਾਰ ਕਰ ਸਕਦੇ ਹਨ।

ਇਹ ਸਭ ਡਾਇਗਨੌਸਟਿਕ ਅਤੇ ਪ੍ਰਬੰਧਨ ਉਪਯੋਗਤਾਵਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਦੇ ਨਾਲ ਹੈ, ਜਿਵੇਂ ਕਿ ovs-vsctl, ovs-appctl, ovs-ofctl, ਆਦਿ।

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

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

ਇਹ ਅਸਲ ਲੇਆਉਟ 'ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ?

ਖੈਰ, ਆਓ ਹੁਣ ਅਮਲੀ ਹਿੱਸੇ ਵੱਲ ਵਧੀਏ ਅਤੇ ਵੇਖੀਏ ਕਿ ਇਹ ਸਭ ਅਭਿਆਸ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

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

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

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

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

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

ਤੁਸੀਂ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਨੇਸਟਡ ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਸਮਰੱਥ ਹੈ ਜਾਂ ਨਹੀਂ ਇਸ ਤਰ੍ਹਾਂ:

[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 

ਜੇਕਰ ਤੁਸੀਂ ਅੱਖਰ N ਦੇਖਦੇ ਹੋ, ਤਾਂ ਅਸੀਂ ਕਿਸੇ ਵੀ ਗਾਈਡ ਦੇ ਅਨੁਸਾਰ ਨੇਸਟਡ ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਲਈ ਸਮਰਥਨ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੇ ਹਾਂ ਜੋ ਤੁਸੀਂ ਨੈੱਟਵਰਕ 'ਤੇ ਲੱਭਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ ਅਜਿਹੇ ਇੱਕ .

ਸਾਨੂੰ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਤੋਂ ਹੇਠਾਂ ਦਿੱਤੇ ਸਰਕਟ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:

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

[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1        
<network>
  <name>ovs-network-1</name>
  <uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
  <forward mode='bridge'/>
  <bridge name='ovs-br1'/>
  <virtualport type='openvswitch'/>
  <portgroup name='trunk-1'>
    <vlan trunk='yes'>
      <tag id='100'/>
      <tag id='101'/>
      <tag id='102'/>
    </vlan>
  </portgroup>
  <portgroup name='access-100'>
    <vlan>
      <tag id='100'/>
    </vlan>
  </portgroup>
  <portgroup name='access-101'>
    <vlan>
      <tag id='101'/>
    </vlan>
  </portgroup>
</network>

ਇੱਥੇ ਤਿੰਨ ਪੋਰਟ ਸਮੂਹ ਘੋਸ਼ਿਤ ਕੀਤੇ ਗਏ ਹਨ - ਦੋ ਐਕਸੈਸ ਅਤੇ ਇੱਕ ਟਰੰਕ (ਬਾਅਦ ਦੀ DNS ਸਰਵਰ ਲਈ ਲੋੜ ਸੀ, ਪਰ ਤੁਸੀਂ ਇਸ ਤੋਂ ਬਿਨਾਂ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਇਸਨੂੰ ਹੋਸਟ ਮਸ਼ੀਨ 'ਤੇ ਸਥਾਪਿਤ ਕਰ ਸਕਦੇ ਹੋ - ਜੋ ਵੀ ਤੁਹਾਡੇ ਲਈ ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਹੈ)। ਅੱਗੇ, ਇਸ ਟੈਂਪਲੇਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ virsh net-define ਦੁਆਰਾ ਘੋਸ਼ਿਤ ਕਰਦੇ ਹਾਂ:

virsh net-define ovs-network-1.xml 
virsh net-start ovs-network-1 
virsh net-autostart ovs-network-1 

ਹੁਣ ਅਸੀਂ ਹਾਈਪਰਵਾਈਜ਼ਰ ਪੋਰਟ ਸੰਰਚਨਾ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਦੇ ਹਾਂ:

[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0   
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1 
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# 

ਨੋਟ: ਇਸ ਦ੍ਰਿਸ਼ ਵਿੱਚ, ਪੋਰਟ ovs-br1 ਦਾ ਪਤਾ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ vlan ਟੈਗ ਨਹੀਂ ਹੈ। ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ sudo ovs-vsctl set port ovs-br1 tag=100 ਕਮਾਂਡ ਜਾਰੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਹਾਲਾਂਕਿ, ਇੱਕ ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ, ਇਹ ਟੈਗ ਅਲੋਪ ਹੋ ਜਾਵੇਗਾ (ਜੇ ਕੋਈ ਜਾਣਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਸਥਾਨ ਵਿੱਚ ਕਿਵੇਂ ਰੱਖਣਾ ਹੈ, ਤਾਂ ਮੈਂ ਬਹੁਤ ਧੰਨਵਾਦੀ ਹੋਵਾਂਗਾ). ਪਰ ਇਹ ਇੰਨਾ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਸਾਨੂੰ ਸਿਰਫ ਇੰਸਟਾਲੇਸ਼ਨ ਦੌਰਾਨ ਇਸ ਪਤੇ ਦੀ ਲੋੜ ਪਵੇਗੀ ਅਤੇ ਓਪਨਸਟੈਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤੈਨਾਤ ਹੋਣ 'ਤੇ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਪਵੇਗੀ।

ਅੱਗੇ, ਅਸੀਂ ਇੱਕ ਅੰਡਰ ਕਲਾਉਡ ਮਸ਼ੀਨ ਬਣਾਉਂਦੇ ਹਾਂ:

virt-install  -n undercloud --description "undercloud"  --os-type=Linux  --os-variant=centos7.0  --ram=8192  --vcpus=8  --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none  --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0

ਇੰਸਟਾਲੇਸ਼ਨ ਦੇ ਦੌਰਾਨ, ਤੁਸੀਂ ਸਾਰੇ ਲੋੜੀਂਦੇ ਮਾਪਦੰਡਾਂ ਨੂੰ ਸੈੱਟ ਕਰਦੇ ਹੋ, ਜਿਵੇਂ ਕਿ ਮਸ਼ੀਨ ਦਾ ਨਾਮ, ਪਾਸਵਰਡ, ਉਪਭੋਗਤਾ, ਐਨਟੀਪੀ ਸਰਵਰ, ਆਦਿ, ਤੁਸੀਂ ਤੁਰੰਤ ਪੋਰਟਾਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਮੇਰੇ ਲਈ ਨਿੱਜੀ ਤੌਰ 'ਤੇ, ਇੰਸਟਾਲੇਸ਼ਨ ਤੋਂ ਬਾਅਦ, ਮਸ਼ੀਨ ਰਾਹੀਂ ਲੌਗਇਨ ਕਰਨਾ ਆਸਾਨ ਹੈ. ਕੰਸੋਲ ਅਤੇ ਲੋੜੀਂਦੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਠੀਕ ਕਰੋ. ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਤਿਆਰ-ਕੀਤੀ ਚਿੱਤਰ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਉਹ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਮੈਂ ਕੀਤਾ ਹੈ - ਨਿਊਨਤਮ Centos 7 ਚਿੱਤਰ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰੋ ਅਤੇ VM ਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਲਈ ਇਸਦੀ ਵਰਤੋਂ ਕਰੋ.

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

[root@hp-gen9 bormoglotx]# virsh list
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 62    undercloud                     running

ਪਹਿਲਾਂ, ਇੰਸਟਾਲੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਲਈ ਲੋੜੀਂਦੇ ਸਾਧਨਾਂ ਨੂੰ ਸਥਾਪਿਤ ਕਰੋ:

sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool

ਅੰਡਰਕਲਾਉਡ ਸਥਾਪਨਾ

ਅਸੀਂ ਇੱਕ ਸਟੈਕ ਉਪਭੋਗਤਾ ਬਣਾਉਂਦੇ ਹਾਂ, ਇੱਕ ਪਾਸਵਰਡ ਸੈਟ ਕਰਦੇ ਹਾਂ, ਇਸਨੂੰ sudoer ਵਿੱਚ ਜੋੜਦੇ ਹਾਂ ਅਤੇ ਉਸਨੂੰ ਪਾਸਵਰਡ ਦਰਜ ਕੀਤੇ ਬਿਨਾਂ sudo ਦੁਆਰਾ ਰੂਟ ਕਮਾਂਡਾਂ ਨੂੰ ਚਲਾਉਣ ਦੀ ਯੋਗਤਾ ਦਿੰਦੇ ਹਾਂ:

useradd stack
passwd stack

echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

ਹੁਣ ਅਸੀਂ ਮੇਜ਼ਬਾਨ ਫਾਈਲ ਵਿੱਚ ਪੂਰਾ ਅੰਡਰਕਲਾਉਡ ਨਾਮ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ:

vi /etc/hosts

127.0.0.1   undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

ਅੱਗੇ, ਅਸੀਂ ਰਿਪੋਜ਼ਟਰੀਆਂ ਜੋੜਦੇ ਹਾਂ ਅਤੇ ਸਾਨੂੰ ਲੋੜੀਂਦੇ ਸੌਫਟਵੇਅਰ ਨੂੰ ਸਥਾਪਿਤ ਕਰਦੇ ਹਾਂ:

sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansible

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

ਅੱਗੇ, ਅੰਡਰਕਲਾਉਡ ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਨੂੰ ਉਪਭੋਗਤਾ ਦੀ ਹੋਮ ਡਾਇਰੈਕਟਰੀ ਸਟੈਕ ਵਿੱਚ ਕਾਪੀ ਕਰੋ:

cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

ਹੁਣ ਸਾਨੂੰ ਇਸ ਫਾਈਲ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਇਸਨੂੰ ਸਾਡੀ ਇੰਸਟਾਲੇਸ਼ਨ ਵਿੱਚ ਐਡਜਸਟ ਕਰਨਾ।

ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਲਾਈਨਾਂ ਨੂੰ ਫਾਈਲ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ:

vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10

ਤਾਂ, ਆਓ ਸੈਟਿੰਗਾਂ 'ਤੇ ਚੱਲੀਏ:

undercloud_hostname - ਅੰਡਰਕਲਾਉਡ ਸਰਵਰ ਦਾ ਪੂਰਾ ਨਾਮ, DNS ਸਰਵਰ 'ਤੇ ਐਂਟਰੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

local_ip — ਨੈੱਟਵਰਕ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਲਈ ਸਥਾਨਕ ਅੰਡਰਕਲਾਊਡ ਪਤਾ

ਨੈੱਟਵਰਕ_ਗੇਟਵੇ — ਉਹੀ ਸਥਾਨਕ ਪਤਾ, ਜੋ ਓਵਰਕਲਾਊਡ ਨੋਡਸ ਦੀ ਸਥਾਪਨਾ ਦੇ ਦੌਰਾਨ ਬਾਹਰੀ ਸੰਸਾਰ ਤੱਕ ਪਹੁੰਚ ਲਈ ਇੱਕ ਗੇਟਵੇ ਵਜੋਂ ਕੰਮ ਕਰੇਗਾ, ਸਥਾਨਕ ਆਈਪੀ ਨਾਲ ਵੀ ਮੇਲ ਖਾਂਦਾ ਹੈ।

undercloud_public_host — ਬਾਹਰੀ API ਐਡਰੈੱਸ, ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਨੈੱਟਵਰਕ ਤੋਂ ਕੋਈ ਵੀ ਮੁਫਤ ਪਤਾ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ

undercloud_admin_host ਅੰਦਰੂਨੀ API ਐਡਰੈੱਸ, ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਨੈੱਟਵਰਕ ਤੋਂ ਕੋਈ ਵੀ ਮੁਫ਼ਤ ਪਤਾ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ

undercloud_nameservers - DNS ਸਰਵਰ

generate_service_certificate - ਮੌਜੂਦਾ ਉਦਾਹਰਨ ਵਿੱਚ ਇਹ ਲਾਈਨ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਗਲਤ 'ਤੇ ਸੈੱਟ ਨਹੀਂ ਕੀਤਾ ਤਾਂ ਤੁਹਾਨੂੰ ਇੰਸਟਾਲੇਸ਼ਨ ਦੌਰਾਨ ਇੱਕ ਗਲਤੀ ਮਿਲੇਗੀ, ਸਮੱਸਿਆ ਦਾ ਵਰਣਨ Red Hat ਬੱਗ ਟਰੈਕਰ 'ਤੇ ਕੀਤਾ ਗਿਆ ਹੈ।

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

local_mtu - MTU. ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਇੱਕ ਟੈਸਟ ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਹੈ ਅਤੇ ਮੇਰੇ ਕੋਲ OVS ਸਵਿੱਚ ਪੋਰਟਾਂ 'ਤੇ 1500 ਦਾ MTU ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ 1450 'ਤੇ ਸੈੱਟ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ ਤਾਂ ਜੋ VxLAN ਵਿੱਚ ਸ਼ਾਮਲ ਪੈਕੇਟ ਲੰਘ ਸਕਣ।

network_cidr - ਮਨਜੂਰੀ ਨੈੱਟਵਰਕ

ਮਖੌਟਾ - ਇੱਕ ਬਾਹਰੀ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ NAT ਦੀ ਵਰਤੋਂ ਕਰਨਾ

masquerade_network - ਨੈੱਟਵਰਕ ਜੋ NATEਡ ਹੋਵੇਗਾ

dhcp_ਸ਼ੁਰੂ ਕਰੋ — ਐਡਰੈੱਸ ਪੂਲ ਦਾ ਸ਼ੁਰੂਆਤੀ ਪਤਾ ਜਿੱਥੋਂ ਓਵਰਕਲਾਉਡ ਤੈਨਾਤੀ ਦੌਰਾਨ ਪਤੇ ਨੋਡਾਂ ਨੂੰ ਦਿੱਤੇ ਜਾਣਗੇ

dhcp_end - ਐਡਰੈੱਸ ਪੂਲ ਦਾ ਅੰਤਮ ਪਤਾ ਜਿੱਥੋਂ ਓਵਰਕਲਾਉਡ ਤੈਨਾਤੀ ਦੌਰਾਨ ਪਤੇ ਨੋਡਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤੇ ਜਾਣਗੇ

ਨਿਰੀਖਣ_iprange - ਆਤਮ ਨਿਰੀਖਣ ਲਈ ਜ਼ਰੂਰੀ ਪਤਿਆਂ ਦਾ ਇੱਕ ਪੂਲ (ਉਪਰੋਕਤ ਪੂਲ ਨਾਲ ਓਵਰਲੈਪ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ)

ਸ਼ਡਿਊਲਰ_ਮੈਕਸ_ਟੈਂਪਟਸ - ਓਵਰਕਲਾਉਡ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਗਿਣਤੀ (ਨੋਡਾਂ ਦੀ ਗਿਣਤੀ ਤੋਂ ਵੱਧ ਜਾਂ ਬਰਾਬਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ)

ਫਾਈਲ ਦੇ ਵਰਣਨ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਅੰਡਰਕਲਾਉਡ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਲਈ ਕਮਾਂਡ ਦੇ ਸਕਦੇ ਹੋ:

openstack undercloud install

ਤੁਹਾਡੇ ਆਇਰਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦਿਆਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ 10 ਤੋਂ 30 ਮਿੰਟ ਲੱਗਦੇ ਹਨ। ਆਖਰਕਾਰ ਤੁਹਾਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦਾ ਆਉਟਪੁੱਟ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ:

vi undercloud.conf
2020-08-13 23:13:12,668 INFO: 
#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and should be
secured.

#############################################################################

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

ਜੇਕਰ ਤੁਸੀਂ ifconfig ਆਉਟਪੁੱਟ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਦੇਖੋਗੇ ਕਿ ਇੱਕ ਨਵਾਂ ਬ੍ਰਿਜ ਇੰਟਰਫੇਸ ਪ੍ਰਗਟ ਹੋਇਆ ਹੈ

[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.1  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe2c:89e  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:2c:08:9e  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1095 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1292 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ਓਵਰਕਲਾਉਡ ਤੈਨਾਤੀ ਹੁਣ ਇਸ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਕੀਤੀ ਜਾਵੇਗੀ।

ਹੇਠਾਂ ਦਿੱਤੇ ਆਉਟਪੁੱਟ ਤੋਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਸਾਡੇ ਕੋਲ ਇੱਕ ਨੋਡ 'ਤੇ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਹਨ:

(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name                | Service   | Zone     |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute   | nova     |
+--------------------------+-----------+----------+

ਹੇਠਾਂ ਅੰਡਰਕਲਾਉਡ ਨੈਟਵਰਕ ਹਿੱਸੇ ਦੀ ਸੰਰਚਨਾ ਹੈ:

(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json 
{
    "network_config": [
        {
            "addresses": [
                {
                    "ip_netmask": "192.168.255.1/24"
                }
            ],
            "members": [
                {
                    "dns_servers": [
                        "192.168.255.253"
                    ],
                    "mtu": 1450,
                    "name": "eth0",
                    "primary": "true",
                    "type": "interface"
                }
            ],
            "mtu": 1450,
            "name": "br-ctlplane",
            "ovs_extra": [
                "br-set-external-id br-ctlplane bridge-id br-ctlplane"
            ],
            "routes": [],
            "type": "ovs_bridge"
        }
    ]
}
(undercloud) [stack@undercloud ~]$

ਓਵਰਕਲਾਉਡ ਸਥਾਪਨਾ

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

ਆਉ ਸਾਡੀਆਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਦੀਆਂ ਡਿਸਕਾਂ ਦੇ ਨਾਲ ਫੋਲਡਰ 'ਤੇ ਚੱਲੀਏ ਅਤੇ ਲੋੜੀਂਦੇ ਆਕਾਰ ਦੀਆਂ ਡਿਸਕਾਂ ਬਣਾਓ:

cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160G

ਕਿਉਂਕਿ ਅਸੀਂ ਰੂਟ ਦੇ ਤੌਰ ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ, ਸਾਨੂੰ ਇਹਨਾਂ ਡਿਸਕਾਂ ਦੇ ਮਾਲਕ ਨੂੰ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਜੋ ਅਧਿਕਾਰਾਂ ਨਾਲ ਕੋਈ ਸਮੱਸਿਆ ਨਾ ਆਵੇ:

[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]# 
[root@hp-gen9 images]# 
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# 

ਨੋਟ: ਜੇਕਰ ਤੁਸੀਂ ਇਸਦਾ ਅਧਿਐਨ ਕਰਨ ਲਈ ceph ਨੂੰ ਇੰਸਟਾਲ ਕਰਨ ਦੀ ਯੋਜਨਾ ਨਹੀਂ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਕਮਾਂਡਾਂ ਘੱਟੋ-ਘੱਟ ਦੋ ਡਿਸਕਾਂ ਦੇ ਨਾਲ ਘੱਟੋ-ਘੱਟ 3 ਨੋਡ ਨਹੀਂ ਬਣਾਉਂਦੀਆਂ, ਪਰ ਟੈਪਲੇਟ ਵਿੱਚ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਵਰਚੁਅਲ ਡਿਸਕਾਂ vda, vdb, ਆਦਿ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਵੇਗੀ।

ਬਹੁਤ ਵਧੀਆ, ਹੁਣ ਸਾਨੂੰ ਇਹਨਾਂ ਸਾਰੀਆਂ ਮਸ਼ੀਨਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:

virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml  

virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml  

virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml  

virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml  

virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml 

ਅੰਤ ਵਿੱਚ ਇੱਕ ਕਮਾਂਡ ਹੈ -print-xml > /tmp/storage-1.xml, ਜੋ ਕਿ /tmp/ ਫੋਲਡਰ ਵਿੱਚ ਹਰੇਕ ਮਸ਼ੀਨ ਦੇ ਵੇਰਵੇ ਨਾਲ ਇੱਕ xml ਫਾਈਲ ਬਣਾਉਂਦਾ ਹੈ; ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਨਹੀਂ ਜੋੜਦੇ, ਤਾਂ ਤੁਸੀਂ ਨਹੀਂ ਹੋਵੋਗੇ। ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਦੀ ਪਛਾਣ ਕਰਨ ਦੇ ਯੋਗ।

ਹੁਣ ਸਾਨੂੰ ਇਹਨਾਂ ਸਾਰੀਆਂ ਮਸ਼ੀਨਾਂ ਨੂੰ virsh ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:

virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

ਹੁਣ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਸੂਝ - ਟ੍ਰਿਪਲਓ ਇੰਸਟਾਲੇਸ਼ਨ ਅਤੇ ਆਤਮ-ਨਿਰੀਖਣ ਦੌਰਾਨ ਸਰਵਰਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ IPMI ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

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

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

vbmc ਇੰਸਟਾਲ ਕਰੋ:

yum install yum install python2-virtualbmc

ਜੇਕਰ ਤੁਹਾਡਾ OS ਪੈਕੇਜ ਨਹੀਂ ਲੱਭ ਸਕਦਾ, ਤਾਂ ਰਿਪੋਜ਼ਟਰੀ ਸ਼ਾਮਲ ਕਰੋ:

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

ਹੁਣ ਅਸੀਂ ਉਪਯੋਗਤਾ ਸਥਾਪਤ ਕਰਦੇ ਹਾਂ। ਇੱਥੇ ਸਭ ਕੁਝ ਬੇਇੱਜ਼ਤੀ ਦੇ ਬਿੰਦੂ ਤੱਕ ਮਾਮੂਲੀ ਹੈ. ਹੁਣ ਇਹ ਤਰਕਪੂਰਨ ਹੈ ਕਿ vbmc ਸੂਚੀ ਵਿੱਚ ਕੋਈ ਸਰਵਰ ਨਹੀਂ ਹਨ

[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]# 

ਉਹਨਾਂ ਦੇ ਪ੍ਰਗਟ ਹੋਣ ਲਈ, ਉਹਨਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦਸਤੀ ਘੋਸ਼ਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ:

[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1   | down   | ::      | 7004 |
| compute-2   | down   | ::      | 7005 |
| control-1   | down   | ::      | 7001 |
| storage-1   | down   | ::      | 7002 |
| storage-2   | down   | ::      | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#

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

[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1 
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status  | Address | Port |
+-------------+---------+---------+------+
| compute-1   | running | ::      | 7004 |
| compute-2   | running | ::      | 7005 |
| control-1   | running | ::      | 7001 |
| storage-1   | running | ::      | 7002 |
| storage-2   | running | ::      | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#

ਅਤੇ ਅੰਤਮ ਸੰਪਰਕ - ਤੁਹਾਨੂੰ ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ (ਜਾਂ ਇਸਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਯੋਗ ਕਰੋ):

firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload

ਹੁਣ ਆਉ ਅੰਡਰਕਲਾਉਡ 'ਤੇ ਚੱਲੀਏ ਅਤੇ ਜਾਂਚ ਕਰੀਏ ਕਿ ਸਭ ਕੁਝ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਹੋਸਟ ਮਸ਼ੀਨ ਦਾ ਪਤਾ 192.168.255.200 ਹੈ, ਅੰਡਰਕਲਾਉਡ 'ਤੇ ਅਸੀਂ ਤੈਨਾਤੀ ਦੀ ਤਿਆਰੀ ਦੌਰਾਨ ਲੋੜੀਂਦੇ ipmitool ਪੈਕੇਜ ਨੂੰ ਜੋੜਿਆ ਹੈ:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status          
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list 
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 65    control-1                      running

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਅਸੀਂ vbmc ਦੁਆਰਾ ਕੰਟਰੋਲ ਨੋਡ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਲਾਂਚ ਕੀਤਾ ਹੈ। ਆਓ ਹੁਣ ਇਸਨੂੰ ਬੰਦ ਕਰੀਏ ਅਤੇ ਅੱਗੇ ਵਧੀਏ:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

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

[root@hp-gen9 ~]# virsh domiflist --domain control-1 
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:20:a2:2f
-          network    ovs-network-1 virtio      52:54:00:3f:87:9f

[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:98:e9:d6

[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:6a:ea:be

[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:79:0b:cb

[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:a7:fe:27

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

ਹੁਣ ਅਸੀਂ json ਫਾਈਲ ਤਿਆਰ ਕਰਦੇ ਹਾਂ। ਸਾਨੂੰ ਪੋਰਟ ਦੇ ਪੋਪੀ ਐਡਰੈੱਸ ਨੂੰ ਦਰਸਾਉਣ ਦੀ ਲੋੜ ਹੈ ਜਿਸ ਰਾਹੀਂ ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਕੀਤੀ ਜਾਵੇਗੀ, ਨੋਡਾਂ ਦੇ ਮਾਪਦੰਡ, ਉਹਨਾਂ ਨੂੰ ਨਾਮ ਦਿਓ ਅਤੇ ipmi ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਣਾ ਹੈ:

{
    "nodes":[
        {
            "mac":[
                "52:54:00:20:a2:2f"
            ],
            "cpu":"8",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"control-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7001"
        },
        {
            "mac":[
                "52:54:00:79:0b:cb"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7002"
        },
        {
            "mac":[
                "52:54:00:a7:fe:27"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7003"
        },
        {
            "mac":[
                "52:54:00:98:e9:d6"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7004"
        },
        {
            "mac":[
                "52:54:00:6a:ea:be"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7005"
        }
    ]
}

ਹੁਣ ਸਾਨੂੰ ਵਿਅੰਗਾਤਮਕ ਲਈ ਚਿੱਤਰ ਤਿਆਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ. ਅਜਿਹਾ ਕਰਨ ਲਈ, ਉਹਨਾਂ ਨੂੰ wget ਦੁਆਰਾ ਡਾਊਨਲੋਡ ਕਰੋ ਅਤੇ ਸਥਾਪਿਤ ਕਰੋ:

(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack  916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack  15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/                       
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack  53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$

ਅੰਡਰਕਲਾਊਡ 'ਤੇ ਚਿੱਤਰ ਅੱਪਲੋਡ ਕਰਨਾ:

(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
|                  ID                  |          Name          | Disk Format |   Size  | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz |     aki     | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
|                  ID                  |          Name         | Disk Format |   Size   | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd |     ari     | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
|                  ID                  |      Name      | Disk Format |    Size    | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full |    qcow2    | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
|                  ID                  |       Name       | Disk Format |   Size  | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel |     aki     | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
|                  ID                  |        Name       | Disk Format |    Size   | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk |     ari     | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$

ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈ ਕਿ ਸਾਰੀਆਂ ਤਸਵੀਰਾਂ ਲੋਡ ਹੋ ਗਈਆਂ ਹਨ

(undercloud) [stack@undercloud ~]$  openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Name                   | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel       | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk      | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full         | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd  | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$

ਇੱਕ ਹੋਰ ਚੀਜ਼ - ਤੁਹਾਨੂੰ ਇੱਕ DNS ਸਰਵਰ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ:

(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID                                   | Name            | Network                              | Subnet           |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field             | Value                                                     |
+-------------------+-----------------------------------------------------------+
| allocation_pools  | 192.168.255.11-192.168.255.50                             |
| cidr              | 192.168.255.0/24                                          |
| created_at        | 2020-08-13T20:10:37Z                                      |
| description       |                                                           |
| dns_nameservers   |                                                           |
| enable_dhcp       | True                                                      |
| gateway_ip        | 192.168.255.1                                             |
| host_routes       | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id                | f45dea46-4066-42aa-a3c4-6f84b8120cab                      |
| ip_version        | 4                                                         |
| ipv6_address_mode | None                                                      |
| ipv6_ra_mode      | None                                                      |
| name              | ctlplane-subnet                                           |
| network_id        | 6ca013dc-41c2-42d8-9d69-542afad53392                      |
| prefix_length     | None                                                      |
| project_id        | a844ccfcdb2745b198dde3e1b28c40a3                          |
| revision_number   | 0                                                         |
| segment_id        | None                                                      |
| service_types     |                                                           |
| subnetpool_id     | None                                                      |
| tags              |                                                           |
| updated_at        | 2020-08-13T20:10:37Z                                      |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253                                    
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$

ਹੁਣ ਅਸੀਂ ਆਤਮ ਨਿਰੀਖਣ ਲਈ ਹੁਕਮ ਦੇ ਸਕਦੇ ਹਾਂ:

(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json 
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.


5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਆਉਟਪੁੱਟ ਤੋਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਹਰ ਚੀਜ਼ ਬਿਨਾਂ ਕਿਸੇ ਤਰੁੱਟੀ ਦੇ ਪੂਰੀ ਹੋਈ। ਆਉ ਜਾਂਚ ਕਰੀਏ ਕਿ ਸਾਰੇ ਨੋਡ ਉਪਲਬਧ ਸਥਿਤੀ ਵਿੱਚ ਹਨ:

(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID                                 | Name      | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None          | power off   | available          | False       |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None          | power off   | available          | False       |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None          | power off   | available          | False       |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None          | power off   | available          | False       |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None          | power off   | available          | False       |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ 

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

ਅੱਗੇ, ਸਾਨੂੰ ਇਹ ਦਰਸਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਕਿਹੜਾ ਨੋਡ ਕਿਹੜਾ ਫੰਕਸ਼ਨ ਕਰੇਗਾ - ਭਾਵ, ਉਹ ਪ੍ਰੋਫਾਈਲ ਦਰਸਾਓ ਜਿਸ ਨਾਲ ਨੋਡ ਤੈਨਾਤ ਕਰੇਗਾ:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | None            |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | None            |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | None            |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | None            |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | None            |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID                                   | Name          |  RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 |   40 |         0 |     1 | True      |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal     | 4096 |   40 |         0 |     1 | True      |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control       | 4096 |   40 |         0 |     1 | True      |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 |   40 |         0 |     1 | True      |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute       | 4096 |   40 |         0 |     1 | True      |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage  | 4096 |   40 |         0 |     1 | True      |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$

ਹਰੇਕ ਨੋਡ ਲਈ ਪ੍ਰੋਫਾਈਲ ਦਿਓ:

openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167

ਆਓ ਜਾਂਚ ਕਰੀਏ ਕਿ ਅਸੀਂ ਸਭ ਕੁਝ ਸਹੀ ਢੰਗ ਨਾਲ ਕੀਤਾ ਹੈ:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | control         |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | ceph-storage    |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | ceph-storage    |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | compute         |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | compute         |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$

ਜੇ ਸਭ ਕੁਝ ਸਹੀ ਹੈ, ਤਾਂ ਅਸੀਂ ਓਵਰਕਲਾਉਡ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਲਈ ਕਮਾਂਡ ਦਿੰਦੇ ਹਾਂ:

openstack overcloud deploy --templates --control-scale 1 --compute-scale 2  --ceph-storage-scale 2 --control-flavor control --compute-flavor compute  --ceph-storage-flavor ceph-storage --libvirt-type qemu

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

ਨੋਟ: ਇਸ ਕੇਸ ਵਿੱਚ --libvirt-type qemu ਵੇਰੀਏਬਲ ਜ਼ਰੂਰੀ ਹੈ, ਕਿਉਂਕਿ ਅਸੀਂ ਨੇਸਟਡ ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ। ਨਹੀਂ ਤਾਂ, ਤੁਸੀਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਨੂੰ ਚਲਾਉਣ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੋਗੇ।

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

2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE  Stack CREATE completed successfully

 Stack overcloud CREATE_COMPLETE 

Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$

ਹੁਣ ਤੁਹਾਡੇ ਕੋਲ ਓਪਨਸਟੈਕ ਦਾ ਲਗਭਗ ਪੂਰਾ ਸੰਸਕਰਣ ਹੈ, ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਅਧਿਐਨ ਕਰ ਸਕਦੇ ਹੋ, ਪ੍ਰਯੋਗ ਕਰ ਸਕਦੇ ਹੋ, ਆਦਿ।

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

(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID                                   | Name                    | Status | Networks                | Image          | Flavor       |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0  | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control      |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute      |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute      |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$ 

(undercloud) [stack@undercloud ~]$ source overcloudrc 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID                               | Name    |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin   |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$

ਮੇਰੀ ਇੰਸਟਾਲੇਸ਼ਨ ਲਈ ਅਜੇ ਵੀ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਛੋਹ ਦੀ ਲੋੜ ਹੈ - ਕੰਟਰੋਲਰ 'ਤੇ ਇੱਕ ਰੂਟ ਜੋੜਨਾ, ਕਿਉਂਕਿ ਮਸ਼ੀਨ ਜਿਸ ਨਾਲ ਮੈਂ ਕੰਮ ਕਰ ਰਿਹਾ ਹਾਂ ਇੱਕ ਵੱਖਰੇ ਨੈੱਟਵਰਕ 'ਤੇ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਹੀਟ-ਐਡਮਿਨ ਖਾਤੇ ਦੇ ਅਧੀਨ ਕੰਟਰੋਲ-1 'ਤੇ ਜਾਓ ਅਤੇ ਰੂਟ ਨੂੰ ਰਜਿਸਟਰ ਕਰੋ

(undercloud) [stack@undercloud ~]$ ssh [email protected]         
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254

ਖੈਰ, ਹੁਣ ਤੁਸੀਂ ਦੂਰੀ ਵਿੱਚ ਜਾ ਸਕਦੇ ਹੋ। ਸਾਰੀ ਜਾਣਕਾਰੀ - ਪਤੇ, ਲਾਗਇਨ ਅਤੇ ਪਾਸਵਰਡ - ਫਾਈਲ /home/stack/overcloudrc ਵਿੱਚ ਹਨ। ਅੰਤਮ ਚਿੱਤਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ:

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

ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਵਿਚਕਾਰ ਆਵਾਜਾਈ ਕਿਵੇਂ ਚਲਦੀ ਹੈ?

ਇਸ ਲੇਖ ਵਿੱਚ ਅਸੀਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਪਾਸ ਕਰਨ ਲਈ ਤਿੰਨ ਵਿਕਲਪਾਂ ਨੂੰ ਦੇਖਾਂਗੇ

• ਇੱਕ L2 ਨੈੱਟਵਰਕ 'ਤੇ ਇੱਕ ਹਾਈਪਰਵਾਈਜ਼ਰ 'ਤੇ ਦੋ ਮਸ਼ੀਨਾਂ
• ਇੱਕੋ L2 ਨੈੱਟਵਰਕ 'ਤੇ ਵੱਖ-ਵੱਖ ਹਾਈਪਰਵਾਈਜ਼ਰਾਂ 'ਤੇ ਦੋ ਮਸ਼ੀਨਾਂ
• ਵੱਖ-ਵੱਖ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਦੋ ਮਸ਼ੀਨਾਂ (ਕਰਾਸ-ਨੈੱਟਵਰਕ ਰੂਟਿੰਗ)

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

ਜਾਂਚ ਕਰਨ ਲਈ, ਆਓ ਹੇਠਾਂ ਦਿੱਤੇ ਚਿੱਤਰ ਨੂੰ ਇਕੱਠੇ ਕਰੀਏ:

ਅਸੀਂ 4 ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਬਣਾਈਆਂ ਹਨ - 3 ਇੱਕ L2 ਨੈੱਟਵਰਕ 'ਤੇ - ਨੈੱਟ-1, ਅਤੇ 1 ਹੋਰ ਨੈੱਟ-2 ਨੈੱਟਵਰਕ 'ਤੇ।

(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c             
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID                                   | Name | Tenant ID                        | Status | Task State | Power State | Networks        |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-2=10.0.2.8  |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ 

ਆਓ ਦੇਖੀਏ ਕਿ ਬਣਾਈਆਂ ਗਈਆਂ ਮਸ਼ੀਨਾਂ ਕਿਸ ਹਾਈਪਰਵਾਈਜ਼ਰ 'ਤੇ ਸਥਿਤ ਹਨ:

(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-1                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000001                                        |

(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-2                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000002                                        |

(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-3                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000003                                        |

(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-4                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000004                                        |

(ਓਵਰਕਲਾਉਡ) [stack@undercloud ~]$
ਮਸ਼ੀਨਾਂ vm-1 ਅਤੇ vm-3 ਕੰਪਿਊਟ-0 'ਤੇ ਸਥਿਤ ਹਨ, ਮਸ਼ੀਨਾਂ vm-2 ਅਤੇ vm-4 ਨੋਡ ਕੰਪਿਊਟ-1 'ਤੇ ਸਥਿਤ ਹਨ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇੱਕ ਵਰਚੁਅਲ ਰਾਊਟਰ ਨਿਰਧਾਰਿਤ ਨੈੱਟਵਰਕਾਂ ਵਿਚਕਾਰ ਰੂਟਿੰਗ ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ:

(overcloud) [stack@undercloud ~]$ openstack router list  --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID                                   | Name     | Status | State | Distributed | HA    | Project                          |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP    | False       | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ 

ਰਾਊਟਰ ਵਿੱਚ ਦੋ ਵਰਚੁਅਲ ਪੋਰਟ ਹਨ, ਜੋ ਨੈੱਟਵਰਕਾਂ ਲਈ ਗੇਟਵੇ ਵਜੋਂ ਕੰਮ ਕਰਦੇ ਹਨ:

(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info         | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ 

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

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

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

VxLAN ਸੁਰੰਗਾਂ ਦੇ ਪਤਿਆਂ ਨੂੰ ਦੇਖਦੇ ਹੋਏ, ਇਹ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਇੱਕ ਸੁਰੰਗ ਨੂੰ ਕੰਪਿਊਟ-1 (192.168.255.26) ਵੱਲ ਵਧਾਇਆ ਗਿਆ ਹੈ, ਦੂਜੀ ਸੁਰੰਗ ਕੰਟਰੋਲ-1 (192.168.255.15) ਵੱਲ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ। ਪਰ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ br-ex ਵਿੱਚ ਭੌਤਿਕ ਇੰਟਰਫੇਸ ਨਹੀਂ ਹਨ, ਅਤੇ ਜੇ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਕਿ ਕਿਹੜੇ ਵਹਾਅ ਨੂੰ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਇਹ ਪੁਲ ਸਿਰਫ ਇਸ ਸਮੇਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਛੱਡ ਸਕਦਾ ਹੈ.

[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.19  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe6a:eabe  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:6a:ea:be  txqueuelen 1000  (Ethernet)
        RX packets 2909669  bytes 4608201000 (4.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1821057  bytes 349198520 (333.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-novacompute-0 ~]$ 

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

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-ofctl dump-flows br-ex
 cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
 cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$ 

ਪਹਿਲੇ ਨਿਯਮ ਦੇ ਅਨੁਸਾਰ, ਫਾਈ-ਬ੍ਰ-ਐਕਸ ਪੋਰਟ ਤੋਂ ਆਈ ਹਰ ਚੀਜ਼ ਨੂੰ ਰੱਦ ਕਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।
ਵਾਸਤਵ ਵਿੱਚ, ਇਸ ਸਮੇਂ ਇਸ ਇੰਟਰਫੇਸ (br-int ਦੇ ਨਾਲ ਇੰਟਰਫੇਸ) ਤੋਂ ਇਲਾਵਾ ਇਸ ਬ੍ਰਿਜ ਵਿੱਚ ਆਵਾਜਾਈ ਲਈ ਹੋਰ ਕਿਤੇ ਵੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਬੂੰਦਾਂ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, BUM ਟ੍ਰੈਫਿਕ ਪਹਿਲਾਂ ਹੀ ਪੁਲ ਵਿੱਚ ਵਹਿ ਗਿਆ ਹੈ।

ਭਾਵ, ਟ੍ਰੈਫਿਕ ਇਸ ਨੋਡ ਨੂੰ ਸਿਰਫ VxLAN ਸੁਰੰਗ ਰਾਹੀਂ ਛੱਡ ਸਕਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ। ਹਾਲਾਂਕਿ, ਜੇਕਰ ਤੁਸੀਂ DVR ਨੂੰ ਚਾਲੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਥਿਤੀ ਬਦਲ ਜਾਵੇਗੀ, ਪਰ ਅਸੀਂ ਕਿਸੇ ਹੋਰ ਸਮੇਂ ਇਸ ਨਾਲ ਨਜਿੱਠਾਂਗੇ। ਨੈੱਟਵਰਕ ਆਈਸੋਲੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਉਦਾਹਰਨ ਲਈ vlans ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਤੁਹਾਡੇ ਕੋਲ vlan 3 ਵਿੱਚ ਇੱਕ L0 ਇੰਟਰਫੇਸ ਨਹੀਂ ਹੋਵੇਗਾ, ਪਰ ਕਈ ਇੰਟਰਫੇਸ ਹੋਣਗੇ। ਹਾਲਾਂਕਿ, VxLAN ਟ੍ਰੈਫਿਕ ਨੋਡ ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਛੱਡ ਦੇਵੇਗਾ, ਪਰ ਕਿਸੇ ਕਿਸਮ ਦੇ ਸਮਰਪਿਤ vlan ਵਿੱਚ ਵੀ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਵੇਗਾ।

ਅਸੀਂ ਕੰਪਿਊਟ ਨੋਡ ਨੂੰ ਛਾਂਟ ਲਿਆ ਹੈ, ਆਓ ਕੰਟਰੋਲ ਨੋਡ 'ਤੇ ਚੱਲੀਏ।

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
  br-ex:
    br-ex 65534/1: (internal)
    eth0 1/2: (system)
    phy-br-ex 2/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/3: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/4: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$

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

[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.15  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe20:a22f  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:20:a2:2f  txqueuelen 1000  (Ethernet)
        RX packets 803859  bytes 1732616116 (1.6 GiB)
        RX errors 0  dropped 63  overruns 0  frame 0
        TX packets 808475  bytes 121652156 (116.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
    3   100  28:c0:da:00:4d:d3   35
    1     0  28:c0:da:00:4d:d3   35
    1     0  52:54:00:98:e9:d6    0
LOCAL     0  52:54:00:20:a2:2f    0
    1     0  52:54:00:2c:08:9e    0
    3   100  52:54:00:20:a2:2f    0
    1     0  52:54:00:6a:ea:be    0
[heat-admin@overcloud-controller-0 ~]$ 

ਇਹ ਪੋਰਟ ਬੀਆਰ-ਐਕਸ ਬ੍ਰਿਜ ਨਾਲ ਬੰਨ੍ਹਿਆ ਹੋਇਆ ਹੈ ਅਤੇ ਕਿਉਂਕਿ ਇਸ 'ਤੇ ਕੋਈ ਵੀਲੈਨ ਟੈਗ ਨਹੀਂ ਹਨ, ਇਹ ਪੋਰਟ ਇੱਕ ਟਰੰਕ ਪੋਰਟ ਹੈ ਜਿਸ 'ਤੇ ਸਾਰੇ ਵਲੈਨਾਂ ਦੀ ਆਗਿਆ ਹੈ, ਹੁਣ ਆਵਾਜਾਈ ਬਿਨਾਂ ਟੈਗ ਦੇ ਬਾਹਰ ਜਾਂਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ vlan-id 0 ਦੁਆਰਾ ਦਰਸਾਏ ਗਏ ਹਨ। ਉੱਪਰ ਆਉਟਪੁੱਟ.

ਇਸ ਸਮੇਂ ਬਾਕੀ ਸਭ ਕੁਝ ਕੰਪਿਊਟ ਨੋਡ ਦੇ ਸਮਾਨ ਹੈ - ਉਹੀ ਪੁਲ, ਉਹੀ ਸੁਰੰਗਾਂ ਜੋ ਦੋ ਕੰਪਿਊਟ ਨੋਡਾਂ ਨੂੰ ਜਾਂਦੀਆਂ ਹਨ।

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

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

ਹੁਣ ਤੱਕ ਸਾਡਾ ਨੈੱਟਵਰਕ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ:

ਸਾਡੇ ਕੋਲ ਹਰੇਕ ਕੰਪਿਊਟਰ ਨੋਡ 'ਤੇ ਦੋ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਹਨ। ਉਦਾਹਰਨ ਦੇ ਤੌਰ 'ਤੇ ਗਣਨਾ-0 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਆਓ ਦੇਖੀਏ ਕਿ ਸਭ ਕੁਝ ਕਿਵੇਂ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੈ।

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list 
 Id    Name                           State
----------------------------------------------------
 1     instance-00000001              running
 3     instance-00000003              running

[heat-admin@overcloud-novacompute-0 ~]$ 

ਮਸ਼ੀਨ ਦਾ ਸਿਰਫ ਇੱਕ ਵਰਚੁਅਲ ਇੰਟਰਫੇਸ ਹੈ - tap95d96a75-a0:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

ਇਹ ਇੰਟਰਫੇਸ ਲੀਨਕਸ ਬ੍ਰਿਜ ਵਿੱਚ ਦਿਸਦਾ ਹੈ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242904c92a8       no
qbr5bd37136-47          8000.5e4e05841423       no              qvb5bd37136-47
                                                        tap5bd37136-47
qbr95d96a75-a0          8000.de076cb850f6       no              qvb95d96a75-a0
                                                        tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ 

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਆਉਟਪੁੱਟ ਤੋਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਬ੍ਰਿਜ ਵਿੱਚ ਸਿਰਫ ਦੋ ਇੰਟਰਫੇਸ ਹਨ - tap95d96a75-a0 ਅਤੇ qvb95d96a75-a0।

ਓਪਨਸਟੈਕ ਵਿੱਚ ਵਰਚੁਅਲ ਨੈਟਵਰਕ ਡਿਵਾਈਸਾਂ ਦੀਆਂ ਕਿਸਮਾਂ 'ਤੇ ਥੋੜਾ ਜਿਹਾ ਧਿਆਨ ਦੇਣ ਦੇ ਯੋਗ ਹੈ:
vtap - ਇੱਕ ਉਦਾਹਰਣ (VM) ਨਾਲ ਜੁੜਿਆ ਵਰਚੁਅਲ ਇੰਟਰਫੇਸ
qbr - ਲੀਨਕਸ ਬ੍ਰਿਜ
qvb ਅਤੇ qvo - vEth ਜੋੜਾ ਲੀਨਕਸ ਬ੍ਰਿਜ ਅਤੇ ਓਪਨ vSwitch ਬ੍ਰਿਜ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ
br-int, br-tun, br-vlan — ਓਪਨ vSwitch ਬ੍ਰਿਜ
patch-, int-br-, phy-br- - ਪੁਲਾਂ ਨੂੰ ਜੋੜਨ ਵਾਲੇ vSwitch ਪੈਚ ਇੰਟਰਫੇਸ ਖੋਲ੍ਹੋ
qg, qr, ha, fg, sg - OVS ਨਾਲ ਜੁੜਨ ਲਈ ਵਰਚੁਅਲ ਡਿਵਾਈਸਾਂ ਦੁਆਰਾ ਵਰਤੇ ਜਾਂਦੇ vSwitch ਪੋਰਟਾਂ ਨੂੰ ਖੋਲ੍ਹੋ

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ, ਜੇਕਰ ਸਾਡੇ ਕੋਲ ਬ੍ਰਿਜ ਵਿੱਚ ਇੱਕ qvb95d96a75-a0 ਪੋਰਟ ਹੈ, ਜੋ ਕਿ ਇੱਕ vEth ਜੋੜਾ ਹੈ, ਤਾਂ ਕਿਤੇ ਨਾ ਕਿਤੇ ਇਸਦਾ ਵਿਰੋਧੀ ਹੈ, ਜਿਸਨੂੰ ਤਰਕ ਨਾਲ qvo95d96a75-a0 ਕਿਹਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਆਓ ਦੇਖੀਏ ਕਿ OVS 'ਤੇ ਕਿਹੜੀਆਂ ਪੋਰਟਾਂ ਹਨ।

[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
    qvo5bd37136-47 6/6: (system)
    qvo95d96a75-a0 3/5: (system)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ 

ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਦੇਖ ਸਕਦੇ ਹਾਂ, ਪੋਰਟ br-int ਵਿੱਚ ਹੈ. Br-int ਇੱਕ ਸਵਿੱਚ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਪੋਰਟਾਂ ਨੂੰ ਬੰਦ ਕਰਦਾ ਹੈ। qvo95d96a75-a0 ਤੋਂ ਇਲਾਵਾ, ਪੋਰਟ qvo5bd37136-47 ਆਉਟਪੁੱਟ ਵਿੱਚ ਦਿਖਾਈ ਦੇ ਰਿਹਾ ਹੈ। ਇਹ ਦੂਜੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਲਈ ਪੋਰਟ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਸਾਡਾ ਚਿੱਤਰ ਹੁਣ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

ਇੱਕ ਸਵਾਲ ਜੋ ਧਿਆਨ ਦੇਣ ਵਾਲੇ ਪਾਠਕ ਨੂੰ ਤੁਰੰਤ ਦਿਲਚਸਪੀ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ - ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਪੋਰਟ ਅਤੇ OVS ਪੋਰਟ ਦੇ ਵਿਚਕਾਰ ਲੀਨਕਸ ਬ੍ਰਿਜ ਕੀ ਹੈ? ਤੱਥ ਇਹ ਹੈ ਕਿ ਮਸ਼ੀਨ ਦੀ ਸੁਰੱਖਿਆ ਲਈ, ਸੁਰੱਖਿਆ ਸਮੂਹਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਕਿ iptables ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ ਹਨ. OVS iptables ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਇਸ "ਬਸਾਖਾ" ਦੀ ਖੋਜ ਕੀਤੀ ਗਈ ਸੀ। ਹਾਲਾਂਕਿ, ਇਹ ਅਪ੍ਰਚਲਿਤ ਹੋ ਰਿਹਾ ਹੈ - ਇਸਨੂੰ ਨਵੇਂ ਰੀਲੀਜ਼ਾਂ ਵਿੱਚ ਕੰਟਰੈਕ ਦੁਆਰਾ ਬਦਲਿਆ ਜਾ ਰਿਹਾ ਹੈ.

ਭਾਵ, ਆਖਰਕਾਰ ਸਕੀਮ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

ਇੱਕ L2 ਨੈੱਟਵਰਕ 'ਤੇ ਇੱਕ ਹਾਈਪਰਵਾਈਜ਼ਰ 'ਤੇ ਦੋ ਮਸ਼ੀਨਾਂ

ਕਿਉਂਕਿ ਇਹ ਦੋਵੇਂ VM ਇੱਕੋ L2 ਨੈੱਟਵਰਕ 'ਤੇ ਅਤੇ ਇੱਕੋ ਹਾਈਪਰਵਾਈਜ਼ਰ 'ਤੇ ਸਥਿਤ ਹਨ, ਇਸ ਲਈ ਇਹਨਾਂ ਵਿਚਕਾਰ ਟ੍ਰੈਫਿਕ ਤਰਕਪੂਰਣ ਤੌਰ 'ਤੇ br-int ਰਾਹੀਂ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਵਹਿ ਜਾਵੇਗਾ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਮਸ਼ੀਨਾਂ ਇੱਕੋ VLAN 'ਤੇ ਹੋਣਗੀਆਂ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap5bd37136-47 bridge     qbr5bd37136-47 virtio      fa:16:3e:83:ad:a4

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int 
 port  VLAN  MAC                Age
    6     1  fa:16:3e:83:ad:a4    0
    3     1  fa:16:3e:44:98:20    0
[heat-admin@overcloud-novacompute-0 ~]$ 

ਇੱਕੋ L2 ਨੈੱਟਵਰਕ 'ਤੇ ਵੱਖ-ਵੱਖ ਹਾਈਪਰਵਾਈਜ਼ਰਾਂ 'ਤੇ ਦੋ ਮਸ਼ੀਨਾਂ

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

ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਦੇ ਪਤੇ ਜਿਨ੍ਹਾਂ ਦੇ ਵਿਚਕਾਰ ਅਸੀਂ ਟ੍ਰੈਫਿਕ ਦੇਖਾਂਗੇ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tape7e23f1b-07 bridge     qbre7e23f1b-07 virtio      fa:16:3e:72:ad:53

[heat-admin@overcloud-novacompute-1 ~]$ 

ਅਸੀਂ ਕੰਪਿਊਟ-0 'ਤੇ br-int ਵਿੱਚ ਫਾਰਵਰਡਿੰਗ ਟੇਬਲ ਨੂੰ ਦੇਖਦੇ ਹਾਂ:

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
    2     1  fa:16:3e:72:ad:53    1
[heat-admin@overcloud-novacompute-0 ~]

ਟ੍ਰੈਫਿਕ ਨੂੰ ਪੋਰਟ 2 'ਤੇ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ - ਆਓ ਦੇਖੀਏ ਕਿ ਇਹ ਕਿਸ ਕਿਸਮ ਦਾ ਪੋਰਟ ਹੈ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$

ਇਹ ਪੈਚ-ਟੂਨ ਹੈ - ਯਾਨੀ ਬ੍ਰ-ਟੂਨ ਵਿੱਚ ਇੰਟਰਫੇਸ। ਆਓ ਦੇਖੀਏ ਕਿ br-tun 'ਤੇ ਪੈਕੇਜ ਦਾ ਕੀ ਹੁੰਦਾ ਹੈ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
 cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ 

ਪੈਕੇਟ ਨੂੰ VxLAN ਵਿੱਚ ਪੈਕ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਪੋਰਟ 2 'ਤੇ ਭੇਜਿਆ ਗਿਆ ਹੈ। ਆਓ ਦੇਖੀਏ ਕਿ ਪੋਰਟ 2 ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr   
 1(patch-int): addr:b2:d1:f8:21:96:66
 2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
 3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
 LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$

ਇਹ ਕੰਪਿਊਟ-1 'ਤੇ ਇੱਕ vxlan ਸੁਰੰਗ ਹੈ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

ਚਲੋ ਕੰਪਿਊਟ-1 'ਤੇ ਚੱਲੀਏ ਅਤੇ ਦੇਖਦੇ ਹਾਂ ਕਿ ਪੈਕੇਜ ਨਾਲ ਅੱਗੇ ਕੀ ਹੁੰਦਾ ਹੈ:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
    2     1  fa:16:3e:44:98:20    1
[heat-admin@overcloud-novacompute-1 ~]$ 

ਮੈਕ ਕੰਪਿਊਟ-1 'ਤੇ br-int ਫਾਰਵਰਡਿੰਗ ਟੇਬਲ ਵਿੱਚ ਹੈ, ਅਤੇ ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦਿੱਤੇ ਆਉਟਪੁੱਟ ਤੋਂ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਇਹ ਪੋਰਟ 2 ਰਾਹੀਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਜੋ ਕਿ br-tun ਵੱਲ ਪੋਰਟ ਹੈ:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr   
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46

ਖੈਰ, ਫਿਰ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਕੰਪਿਊਟ-1 'ਤੇ br-int ਵਿੱਚ ਇੱਕ ਮੰਜ਼ਿਲ ਪੋਪੀ ਹੈ:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
    3     1  fa:16:3e:72:ad:53    0
[heat-admin@overcloud-novacompute-1 ~]$ 

ਯਾਨੀ, ਪ੍ਰਾਪਤ ਹੋਇਆ ਪੈਕੇਟ ਪੋਰਟ 3 'ਤੇ ਉੱਡ ਜਾਵੇਗਾ, ਜਿਸ ਦੇ ਪਿੱਛੇ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਇੰਸਟੈਂਸ-00000003 ਹੈ।

ਵਰਚੁਅਲ ਬੁਨਿਆਦੀ ਢਾਂਚੇ 'ਤੇ ਸਿੱਖਣ ਲਈ ਓਪਨਸਟੈਕ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਦੀ ਸੁੰਦਰਤਾ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਹਾਈਪਰਵਾਈਜ਼ਰਾਂ ਦੇ ਵਿਚਕਾਰ ਆਵਾਜਾਈ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਕੈਪਚਰ ਕਰ ਸਕਦੇ ਹਾਂ ਅਤੇ ਦੇਖ ਸਕਦੇ ਹਾਂ ਕਿ ਇਸ ਨਾਲ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਇਹ ਉਹ ਹੈ ਜੋ ਅਸੀਂ ਹੁਣ ਕਰਾਂਗੇ, vnet ਪੋਰਟ ਉੱਤੇ tcpdump ਨੂੰ ਕੰਪਿਊਟ-0 ਵੱਲ ਚਲਾਓ:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
	
*****************omitted*******************

ਪਹਿਲੀ ਲਾਈਨ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਪਤੇਕ 10.0.1.85 ਤੋਂ ਪਤਾ 10.0.1.88 (ICMP ਟ੍ਰੈਫਿਕ) 'ਤੇ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹ vni 22 ਦੇ ਨਾਲ ਇੱਕ VxLAN ਪੈਕੇਟ ਵਿੱਚ ਲਪੇਟਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪੈਕੇਟ ਹੋਸਟ 192.168.255.19 (ਕੰਪਿਊਟ-0) ਤੋਂ ਹੋਸਟ 192.168.255.26 ਤੱਕ ਜਾਂਦਾ ਹੈ। .1 (ਗਣਨਾ-XNUMX)। ਅਸੀਂ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ VNI ovs ਵਿੱਚ ਦਰਸਾਏ ਗਏ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।

ਚਲੋ ਇਸ ਲਾਈਨ ਐਕਸ਼ਨਜ਼=ਲੋਡ:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],ਆਉਟਪੁੱਟ:2 'ਤੇ ਵਾਪਸ ਆਉਂਦੇ ਹਾਂ। ਹੈਕਸਾਡੈਸੀਮਲ ਨੰਬਰ ਸਿਸਟਮ ਵਿੱਚ 0x16 vni ਹੈ। ਚਲੋ ਇਸ ਨੰਬਰ ਨੂੰ 16ਵੇਂ ਸਿਸਟਮ ਵਿੱਚ ਬਦਲੀਏ:

16 = 6*16^0+1*16^1 = 6+16 = 22

ਭਾਵ, vni ਅਸਲੀਅਤ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ.

ਦੂਜੀ ਲਾਈਨ ਰਿਟਰਨ ਟ੍ਰੈਫਿਕ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ, ਠੀਕ ਹੈ, ਇਸ ਨੂੰ ਸਮਝਾਉਣ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਹੈ, ਉੱਥੇ ਸਭ ਕੁਝ ਸਪੱਸ਼ਟ ਹੈ.

ਵੱਖ-ਵੱਖ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਦੋ ਮਸ਼ੀਨਾਂ (ਇੰਟਰ-ਨੈੱਟਵਰਕ ਰੂਟਿੰਗ)

ਅੱਜ ਦਾ ਆਖਰੀ ਕੇਸ ਇੱਕ ਵਰਚੁਅਲ ਰਾਊਟਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਦੇ ਅੰਦਰ ਨੈੱਟਵਰਕਾਂ ਵਿਚਕਾਰ ਰੂਟਿੰਗ ਹੈ। ਅਸੀਂ ਇੱਕ ਡੀਵੀਆਰ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਕੇਸ 'ਤੇ ਵਿਚਾਰ ਕਰ ਰਹੇ ਹਾਂ (ਅਸੀਂ ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ ਲੇਖ ਵਿੱਚ ਦੇਖਾਂਗੇ), ਇਸਲਈ ਨੈੱਟਵਰਕ ਨੋਡ 'ਤੇ ਰੂਟਿੰਗ ਹੁੰਦੀ ਹੈ. ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਨੈੱਟਵਰਕ ਨੋਡ ਨੂੰ ਇੱਕ ਵੱਖਰੀ ਹਸਤੀ ਵਿੱਚ ਨਹੀਂ ਰੱਖਿਆ ਗਿਆ ਹੈ ਅਤੇ ਇਹ ਕੰਟਰੋਲ ਨੋਡ 'ਤੇ ਸਥਿਤ ਹੈ।

ਪਹਿਲਾਂ, ਆਓ ਵੇਖੀਏ ਕਿ ਰੂਟਿੰਗ ਕੰਮ ਕਰਦੀ ਹੈ:

$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 ms

ਕਿਉਂਕਿ ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਪੈਕੇਟ ਨੂੰ ਗੇਟਵੇ 'ਤੇ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਉੱਥੇ ਰੂਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਸਾਨੂੰ ਗੇਟਵੇ ਦੇ ਪੋਪੀ ਐਡਰੈੱਸ ਦਾ ਪਤਾ ਲਗਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਜਿਸ ਲਈ ਅਸੀਂ ਉਦਾਹਰਣ ਵਿੱਚ ARP ਟੇਬਲ ਨੂੰ ਦੇਖਦੇ ਹਾਂ:

$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether]  on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether]  on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether]  on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether]  on eth0

ਹੁਣ ਦੇਖਦੇ ਹਾਂ ਕਿ ਮੰਜ਼ਿਲ (10.0.1.254) fa:16:3e:c4:64:70 ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਕਿੱਥੇ ਭੇਜਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
    2     1  fa:16:3e:c4:64:70    0
[heat-admin@overcloud-novacompute-0 ~]$ 

ਆਓ ਦੇਖੀਏ ਕਿ ਪੋਰਟ 2 ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ 

ਸਭ ਕੁਝ ਤਰਕਪੂਰਨ ਹੈ, ਟ੍ਰੈਫਿਕ br-tun ਨੂੰ ਜਾਂਦਾ ਹੈ। ਆਓ ਦੇਖੀਏ ਕਿ ਇਸ ਨੂੰ ਕਿਸ vxlan ਸੁਰੰਗ ਵਿੱਚ ਲਪੇਟਿਆ ਜਾਵੇਗਾ:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
 cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ 

ਤੀਜਾ ਪੋਰਟ ਇੱਕ vxlan ਸੁਰੰਗ ਹੈ:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 

ਜੋ ਕਿ ਕੰਟਰੋਲ ਨੋਡ ਨੂੰ ਵੇਖਦਾ ਹੈ:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

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

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

ਇਸ ਲਈ, ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਗੇਟਵੇ MAC ਐਡਰੈੱਸ ਕੰਟਰੋਲ ਨੋਡ 'ਤੇ br-int ਫਾਰਵਰਡਿੰਗ ਟੇਬਲ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਆਓ ਜਾਂਚ ਕਰੀਏ ਕਿ ਇਹ ਉੱਥੇ ਹੈ ਅਤੇ ਇਹ ਕਿੱਥੇ ਦੇਖ ਰਿਹਾ ਹੈ:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
    5     1  fa:16:3e:c4:64:70    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$  sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

ਮੈਕ ਪੋਰਟ qr-0c52b15f-8f ਤੋਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਓਪਨਸਟੈਕ ਵਿੱਚ ਵਰਚੁਅਲ ਪੋਰਟਾਂ ਦੀ ਸੂਚੀ ਵਿੱਚ ਵਾਪਸ ਜਾਂਦੇ ਹਾਂ, ਤਾਂ ਇਸ ਕਿਸਮ ਦੀ ਪੋਰਟ ਦੀ ਵਰਤੋਂ ਕਈ ਵਰਚੁਅਲ ਡਿਵਾਈਸਾਂ ਨੂੰ OVS ਨਾਲ ਜੋੜਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਵਧੇਰੇ ਸਟੀਕ ਹੋਣ ਲਈ, qr ਵਰਚੁਅਲ ਰਾਊਟਰ ਲਈ ਇੱਕ ਪੋਰਟ ਹੈ, ਜਿਸ ਨੂੰ ਨੇਮਸਪੇਸ ਵਜੋਂ ਦਰਸਾਇਆ ਗਿਆ ਹੈ।

ਆਓ ਦੇਖੀਏ ਕਿ ਸਰਵਰ 'ਤੇ ਕਿਹੜੇ ਨਾਮ-ਸਥਾਨ ਹਨ:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

ਜਿੰਨੀਆਂ ਤਿੰਨ ਕਾਪੀਆਂ। ਪਰ ਨਾਵਾਂ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, ਤੁਸੀਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਦੇ ਉਦੇਸ਼ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਹੋ. ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ID 0 ਅਤੇ 1 ਦੇ ਨਾਲ ਉਦਾਹਰਨਾਂ 'ਤੇ ਵਾਪਸ ਆਵਾਂਗੇ, ਹੁਣ ਸਾਨੂੰ ਨੇਮਸਪੇਸ qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ਵਿੱਚ ਦਿਲਚਸਪੀ ਹੈ:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254 
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254 
[heat-admin@overcloud-controller-0 ~]$ 

ਇਸ ਨੇਮਸਪੇਸ ਵਿੱਚ ਦੋ ਅੰਦਰੂਨੀ ਹਨ ਜੋ ਅਸੀਂ ਪਹਿਲਾਂ ਬਣਾਏ ਹਨ। ਦੋਵੇਂ ਵਰਚੁਅਲ ਪੋਰਟਾਂ ਨੂੰ br-int ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਹੈ। ਆਉ ਪੋਰਟ qr-0c52b15f-8f ਦੇ ਮੈਕ ਐਡਰੈੱਸ ਦੀ ਜਾਂਚ ਕਰੀਏ, ਕਿਉਂਕਿ ਟ੍ਰੈਫਿਕ, ਮੰਜ਼ਿਲ ਮੈਕ ਐਡਰੈੱਸ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, ਇਸ ਇੰਟਰਫੇਸ 'ਤੇ ਗਿਆ ਸੀ।

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.254  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fec4:6470  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:c4:64:70  txqueuelen 1000  (Ethernet)
        RX packets 5356  bytes 427305 (417.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5195  bytes 490603 (479.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 

ਭਾਵ, ਇਸ ਕੇਸ ਵਿੱਚ, ਸਭ ਕੁਝ ਮਿਆਰੀ ਰੂਟਿੰਗ ਦੇ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦਾ ਹੈ. ਕਿਉਂਕਿ ਟ੍ਰੈਫਿਕ ਹੋਸਟ 10.0.2.8 ਲਈ ਨਿਯਤ ਹੈ, ਇਸ ਨੂੰ ਦੂਜੇ ਇੰਟਰਫੇਸ qr-92fa49b5-54 ਤੋਂ ਬਾਹਰ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ vxlan ਸੁਰੰਗ ਰਾਹੀਂ ਕੰਪਿਊਟ ਨੋਡ ਤੱਕ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.1.88                ether   fa:16:3e:72:ad:53   C                     qr-0c52b15f-8f
10.0.1.90                ether   fa:16:3e:83:ad:a4   C                     qr-0c52b15f-8f
10.0.2.8                 ether   fa:16:3e:6c:ad:9c   C                     qr-92fa49b5-54
10.0.2.42                ether   fa:16:3e:f5:0b:29   C                     qr-92fa49b5-54
10.0.1.85                ether   fa:16:3e:44:98:20   C                     qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ 

ਹਰ ਚੀਜ਼ ਲਾਜ਼ੀਕਲ ਹੈ, ਕੋਈ ਹੈਰਾਨੀ ਨਹੀਂ। ਆਓ ਦੇਖੀਏ ਕਿ ਹੋਸਟ 10.0.2.8 ਦਾ ਪੋਪੀ ਐਡਰੈੱਸ br-int ਵਿੱਚ ਕਿੱਥੇ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    2     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

ਜਿਵੇਂ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਟ੍ਰੈਫਿਕ br-tun ਨੂੰ ਜਾਂਦਾ ਹੈ, ਆਓ ਦੇਖੀਏ ਕਿ ਟ੍ਰੈਫਿਕ ਅੱਗੇ ਕਿਹੜੀ ਸੁਰੰਗ ਵਿੱਚ ਜਾਂਦਾ ਹੈ:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
 cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

ਟ੍ਰੈਫਿਕ ਗਣਨਾ-1 ਲਈ ਸੁਰੰਗ ਵਿੱਚ ਜਾਂਦਾ ਹੈ। ਖੈਰ, ਕੰਪਿਊਟ-1 'ਤੇ ਸਭ ਕੁਝ ਸਧਾਰਨ ਹੈ - br-tun ਤੋਂ ਪੈਕੇਜ br-int ਅਤੇ ਉੱਥੋਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਇੰਟਰਫੇਸ 'ਤੇ ਜਾਂਦਾ ਹੈ:

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    4     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr                  
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ 

ਆਓ ਜਾਂਚ ਕਰੀਏ ਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਸਹੀ ਇੰਟਰਫੇਸ ਹੈ:

[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02429c001e1c       no
qbr3210e8ec-c0          8000.ea27f45358be       no              qvb3210e8ec-c0
                                                        tap3210e8ec-c0
qbre7e23f1b-07          8000.b26ac0eded8a       no              qvbe7e23f1b-07
                                                        tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge     qbr3210e8ec-c0 virtio      fa:16:3e:6c:ad:9c

[heat-admin@overcloud-novacompute-1 ~]$

ਅਸਲ ਵਿੱਚ, ਅਸੀਂ ਪੈਕੇਜ ਦੁਆਰਾ ਸਾਰੇ ਤਰੀਕੇ ਨਾਲ ਚਲੇ ਗਏ. ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਦੇਖਿਆ ਹੈ ਕਿ ਟ੍ਰੈਫਿਕ ਵੱਖ-ਵੱਖ vxlan ਸੁਰੰਗਾਂ ਵਿੱਚੋਂ ਲੰਘਿਆ ਅਤੇ ਵੱਖ-ਵੱਖ VNIs ਨਾਲ ਬਾਹਰ ਨਿਕਲਿਆ। ਆਓ ਦੇਖੀਏ ਕਿ ਇਹ ਕਿਸ ਕਿਸਮ ਦੇ VNI ਹਨ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਅਸੀਂ ਨੋਡ ਦੇ ਨਿਯੰਤਰਣ ਪੋਰਟ 'ਤੇ ਇੱਕ ਡੰਪ ਇਕੱਠਾ ਕਰਾਂਗੇ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਵਾਂਗੇ ਕਿ ਉੱਪਰ ਦੱਸੇ ਅਨੁਸਾਰ ਟ੍ਰੈਫਿਕ ਬਿਲਕੁਲ ਵਹਿੰਦਾ ਹੈ।
ਇਸ ਲਈ, ਕੰਪਿਊਟ-0 ਲਈ ਸੁਰੰਗ ਵਿੱਚ ਹੇਠ ਲਿਖੀਆਂ ਕਾਰਵਾਈਆਂ ਹਨ=ਲੋਡ:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],ਆਊਟਪੁੱਟ:3। ਆਓ 0x16 ਨੂੰ ਦਸ਼ਮਲਵ ਸੰਖਿਆ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਬਦਲੀਏ:

0x16 = 6*16^0+1*16^1 = 6+16 = 22

ਕੰਪਿਊਟ-1 ਲਈ ਸੁਰੰਗ ਵਿੱਚ ਹੇਠ ਲਿਖੇ VNI ਹਨ:ਕਿਰਿਆਵਾਂ=ਲੋਡ:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],ਆਊਟਪੁੱਟ:2। ਆਓ 0x63 ਨੂੰ ਦਸ਼ਮਲਵ ਸੰਖਿਆ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਬਦਲੀਏ:

0x63 = 3*16^0+6*16^1 = 3+96 = 99

ਖੈਰ, ਆਓ ਹੁਣ ਡੰਪ ਨੂੰ ਵੇਖੀਏ:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4 
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
	
*****************omitted*******************

ਪਹਿਲਾ ਪੈਕੇਟ ਹੋਸਟ 192.168.255.19 (ਕੰਪਿਊਟ-0) ਤੋਂ vni 192.168.255.15 ਨਾਲ ਹੋਸਟ 1 (ਕੰਟਰੋਲ-22) ਤੱਕ ਇੱਕ vxlan ਪੈਕੇਟ ਹੈ, ਜਿਸ ਦੇ ਅੰਦਰ ਇੱਕ ICMP ਪੈਕੇਟ ਹੋਸਟ 10.0.1.85 ਤੋਂ ਹੋਸਟ 10.0.2.8 ਤੱਕ ਪੈਕ ਕੀਤਾ ਗਿਆ ਹੈ। ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਉੱਪਰ ਗਿਣਿਆ ਹੈ, vni ਉਸ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜੋ ਅਸੀਂ ਆਉਟਪੁੱਟ ਵਿੱਚ ਦੇਖਿਆ ਹੈ।

ਦੂਜਾ ਪੈਕੇਟ ਹੋਸਟ 192.168.255.15 (ਕੰਟਰੋਲ-1) ਤੋਂ vni 192.168.255.26 ਦੇ ਨਾਲ ਹੋਸਟ 1 (ਕੰਪਿਊਟ-99) ਤੱਕ ਇੱਕ vxlan ਪੈਕੇਟ ਹੈ, ਜਿਸ ਦੇ ਅੰਦਰ ਇੱਕ ICMP ਪੈਕੇਟ ਹੋਸਟ 10.0.1.85 ਤੋਂ ਹੋਸਟ 10.0.2.8 ਤੱਕ ਪੈਕ ਕੀਤਾ ਗਿਆ ਹੈ। ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਉੱਪਰ ਗਿਣਿਆ ਹੈ, vni ਉਸ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜੋ ਅਸੀਂ ਆਉਟਪੁੱਟ ਵਿੱਚ ਦੇਖਿਆ ਹੈ।

ਅਗਲੇ ਦੋ ਪੈਕੇਟ 10.0.2.8 ਤੋਂ 10.0.1.85 ਤੋਂ ਵਾਪਸੀ ਟਰੈਫਿਕ ਹਨ।

ਭਾਵ, ਅੰਤ ਵਿੱਚ ਸਾਨੂੰ ਹੇਠ ਲਿਖੀ ਨਿਯੰਤਰਣ ਨੋਡ ਸਕੀਮ ਮਿਲੀ:

ਇਸ ਨੂੰ ਹੈ, ਜੋ ਕਿ ਵਰਗੇ ਵੇਖੋ? ਅਸੀਂ ਦੋ ਨਾਮ-ਸਥਾਨਾਂ ਬਾਰੇ ਭੁੱਲ ਗਏ:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਕਲਾਉਡ ਪਲੇਟਫਾਰਮ ਦੇ ਆਰਕੀਟੈਕਚਰ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਹੈ, ਇਹ ਚੰਗਾ ਹੋਵੇਗਾ ਜੇਕਰ ਮਸ਼ੀਨਾਂ ਇੱਕ DHCP ਸਰਵਰ ਤੋਂ ਆਪਣੇ ਆਪ ਪਤੇ ਪ੍ਰਾਪਤ ਕਰਦੀਆਂ ਹਨ। ਇਹ ਸਾਡੇ ਦੋ ਨੈੱਟਵਰਕ 10.0.1.0/24 ਅਤੇ 10.0.2.0/24 ਲਈ ਦੋ DHCP ਸਰਵਰ ਹਨ।

ਆਓ ਜਾਂਚ ਕਰੀਏ ਕਿ ਇਹ ਸੱਚ ਹੈ। ਇਸ ਨੇਮਸਪੇਸ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਪਤਾ ਹੈ - 10.0.1.1 - ਖੁਦ DHCP ਸਰਵਰ ਦਾ ਪਤਾ, ਅਤੇ ਇਹ br-int ਵਿੱਚ ਵੀ ਸ਼ਾਮਲ ਹੈ:

[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1  bytes 28 (28.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 28 (28.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.1  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fee6:2c5c  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:e6:2c:5c  txqueuelen 1000  (Ethernet)
        RX packets 129  bytes 9372 (9.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 6154 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ਆਓ ਦੇਖੀਏ ਕਿ ਕੀ ਕੰਟਰੋਲ ਨੋਡ 'ਤੇ ਉਹਨਾਂ ਦੇ ਨਾਮ ਵਿੱਚ qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ਵਾਲੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹਨ:

[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 
root      640420  0.0  0.0   4220   348 ?        Ss   11:31   0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+  951620  0.0  0.0 112944   980 pts/0    S+   18:50   0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ 

ਅਜਿਹੀ ਪ੍ਰਕਿਰਿਆ ਹੈ ਅਤੇ ਉਪਰੋਕਤ ਆਉਟਪੁੱਟ ਵਿੱਚ ਪੇਸ਼ ਕੀਤੀ ਗਈ ਜਾਣਕਾਰੀ ਦੇ ਅਧਾਰ ਤੇ, ਅਸੀਂ, ਉਦਾਹਰਨ ਲਈ, ਇਹ ਦੇਖ ਸਕਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਕੋਲ ਵਰਤਮਾਨ ਵਿੱਚ ਕਿਰਾਏ ਲਈ ਕੀ ਹੈ:

[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਨਿਯੰਤਰਣ ਨੋਡ 'ਤੇ ਸੇਵਾਵਾਂ ਦਾ ਨਿਮਨਲਿਖਤ ਸੈੱਟ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ:

ਖੈਰ, ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ - ਇਹ ਸਿਰਫ - 4 ਮਸ਼ੀਨਾਂ, 2 ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ ਅਤੇ ਇੱਕ ਵਰਚੁਅਲ ਰਾਊਟਰ ਹੈ... ਸਾਡੇ ਕੋਲ ਹੁਣ ਇੱਥੇ ਬਾਹਰੀ ਨੈੱਟਵਰਕ ਨਹੀਂ ਹਨ, ਵੱਖ-ਵੱਖ ਪ੍ਰੋਜੈਕਟਾਂ ਦਾ ਇੱਕ ਸਮੂਹ, ਹਰੇਕ ਦੇ ਆਪਣੇ ਨੈੱਟਵਰਕ (ਓਵਰਲੈਪਿੰਗ) ਨਾਲ, ਅਤੇ ਅਸੀਂ ਇੱਕ ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਰਾਊਟਰ ਨੂੰ ਬੰਦ ਕਰ ਦਿੱਤਾ ਹੈ, ਅਤੇ ਅੰਤ ਵਿੱਚ, ਟੈਸਟ ਬੈਂਚ ਵਿੱਚ ਸਿਰਫ ਇੱਕ ਕੰਟਰੋਲ ਨੋਡ ਸੀ (ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਲਈ ਤਿੰਨ ਨੋਡਾਂ ਦਾ ਕੋਰਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ)। ਇਹ ਤਰਕਪੂਰਨ ਹੈ ਕਿ ਵਪਾਰ ਵਿੱਚ ਸਭ ਕੁਝ "ਥੋੜਾ" ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਹੈ, ਪਰ ਇਸ ਸਧਾਰਨ ਉਦਾਹਰਣ ਵਿੱਚ ਅਸੀਂ ਸਮਝਦੇ ਹਾਂ ਕਿ ਇਸਨੂੰ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ - ਭਾਵੇਂ ਤੁਹਾਡੇ ਕੋਲ 3 ਜਾਂ 300 ਨੇਮਸਪੇਸ ਹੋਣ ਬੇਸ਼ੱਕ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਪਰ ਓਪਰੇਸ਼ਨ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਸਾਰਾ ਢਾਂਚਾ, ਕੁਝ ਵੀ ਬਹੁਤਾ ਨਹੀਂ ਬਦਲੇਗਾ... ਹਾਲਾਂਕਿ ਤੁਸੀਂ ਕੁਝ ਵਿਕਰੇਤਾ SDN ਵਿੱਚ ਪਲੱਗ ਨਹੀਂ ਕਰੋਗੇ। ਪਰ ਇਹ ਬਿਲਕੁਲ ਵੱਖਰੀ ਕਹਾਣੀ ਹੈ।

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

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

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

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

ਮੇਰੀ ਰਾਏ ਵਿੱਚ, VMWare ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਨੁਕਸਾਨ ਇਸਦਾ ਪੂਰਾ ਬੰਦ ਹੋਣਾ ਹੈ - ਕੰਪਨੀ ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਕੋਈ ਜਾਣਕਾਰੀ ਨਹੀਂ ਦੇਵੇਗੀ ਕਿ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, vSAN ਜਾਂ ਹਾਈਪਰਵਾਈਜ਼ਰ ਕਰਨਲ ਵਿੱਚ ਕੀ ਹੈ - ਇਹ ਸਿਰਫ਼ ਇਸਦੇ ਲਈ ਲਾਭਦਾਇਕ ਨਹੀਂ ਹੈ - ਭਾਵ, ਤੁਸੀਂ ਕਦੇ ਵੀ VMWare ਵਿੱਚ ਮਾਹਰ ਨਾ ਬਣੋ - ਵਿਕਰੇਤਾ ਦੀ ਸਹਾਇਤਾ ਤੋਂ ਬਿਨਾਂ, ਤੁਸੀਂ ਬਰਬਾਦ ਹੋ ਗਏ ਹੋ (ਬਹੁਤ ਵਾਰ ਮੈਂ VMWare ਮਾਹਰਾਂ ਨੂੰ ਮਿਲਦਾ ਹਾਂ ਜੋ ਮਾਮੂਲੀ ਸਵਾਲਾਂ ਦੁਆਰਾ ਹੈਰਾਨ ਹੁੰਦੇ ਹਨ)। ਮੇਰੇ ਲਈ, VMWare ਹੁੱਡ ਲਾਕ ਵਾਲੀ ਕਾਰ ਖਰੀਦ ਰਿਹਾ ਹੈ - ਹਾਂ, ਤੁਹਾਡੇ ਕੋਲ ਅਜਿਹੇ ਮਾਹਰ ਹੋ ਸਕਦੇ ਹਨ ਜੋ ਟਾਈਮਿੰਗ ਬੈਲਟ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ, ਪਰ ਸਿਰਫ ਉਹੀ ਵਿਅਕਤੀ ਜਿਸ ਨੇ ਤੁਹਾਨੂੰ ਇਹ ਹੱਲ ਵੇਚਿਆ ਹੈ ਹੁੱਡ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ। ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ, ਮੈਨੂੰ ਉਹ ਹੱਲ ਪਸੰਦ ਨਹੀਂ ਹਨ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਮੈਂ ਫਿੱਟ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਤੁਸੀਂ ਕਹੋਗੇ ਕਿ ਤੁਹਾਨੂੰ ਹੁੱਡ ਦੇ ਹੇਠਾਂ ਜਾਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ. ਹਾਂ, ਇਹ ਸੰਭਵ ਹੈ, ਪਰ ਮੈਂ ਤੁਹਾਡੇ ਵੱਲ ਦੇਖਾਂਗਾ ਜਦੋਂ ਤੁਹਾਨੂੰ 20-30 ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ, 40-50 ਨੈਟਵਰਕਾਂ ਤੋਂ ਕਲਾਉਡ ਵਿੱਚ ਇੱਕ ਵੱਡੇ ਫੰਕਸ਼ਨ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਅੱਧੇ ਬਾਹਰ ਜਾਣਾ ਚਾਹੁੰਦੇ ਹਨ, ਅਤੇ ਦੂਜੇ ਅੱਧ ਲਈ ਪੁੱਛਦਾ ਹੈ. SR-IOV ਪ੍ਰਵੇਗ, ਨਹੀਂ ਤਾਂ ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਕਾਰਾਂ ਵਿੱਚੋਂ ਦੋ ਦਰਜਨ ਹੋਰ ਦੀ ਲੋੜ ਪਵੇਗੀ - ਨਹੀਂ ਤਾਂ ਪ੍ਰਦਰਸ਼ਨ ਕਾਫ਼ੀ ਨਹੀਂ ਹੋਵੇਗਾ।

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

ਸਰੋਤ: www.habr.com