AERODISK ਇੰਜਣ: ਤਬਾਹੀ ਪ੍ਰਤੀਰੋਧ। ਭਾਗ 2. ਮੈਟਰੋਕਲੱਸਟਰ

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

ਆਮ ਵਾਂਗ, ਥਿਊਰੀ ਪਹਿਲਾਂ

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

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

ਇਹ ਕੀ ਹੈ?

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

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

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

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

ਇਸ ਨੂੰ ਕੰਮ ਕਰਦਾ ਹੈ?

ਹੇਠਲੇ ਪੱਧਰ 'ਤੇ, ਮੈਟਰੋਕਲੱਸਟਰ ਸਮਕਾਲੀ ਡੇਟਾ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲਈ ਇੱਕ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜਿਸਦਾ ਵਰਣਨ ਅਸੀਂ ਪਿਛਲੇ ਲੇਖ ਵਿੱਚ ਕੀਤਾ ਹੈ (ਵੇਖੋ. ਲਿੰਕ). ਕਿਉਂਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸਮਕਾਲੀ ਹੈ, ਇਸ ਲਈ ਲੋੜਾਂ ਅਨੁਸਾਰੀ ਹਨ, ਜਾਂ ਇਸ ਦੀ ਬਜਾਏ:

• ਭੌਤਿਕ ਵਿਗਿਆਨ ਦੇ ਤੌਰ ਤੇ ਆਪਟੀਕਲ ਫਾਈਬਰ, 10 ਗੀਗਾਬਾਈਟ ਈਥਰਨੈੱਟ (ਜਾਂ ਵੱਧ);
• ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿਚਕਾਰ ਦੂਰੀ 40 ਕਿਲੋਮੀਟਰ ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੈ;
• ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿਚਕਾਰ ਆਪਟੀਕਲ ਚੈਨਲ ਦੇਰੀ (ਸਟੋਰੇਜ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਵਿਚਕਾਰ) 5 ਮਿਲੀਸਕਿੰਟ (ਅਨੁਕੂਲ ਤੌਰ 'ਤੇ 2) ਤੱਕ ਹੈ।

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

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

ਸਾਲਸ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸਦਾ ਕੰਮ ਕੀ ਹੈ?

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

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

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

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

ਆਉ ਹੁਣ ਆਰਬਿਟਰੇਟਰ ਦੇ ਕੰਮ ਦੇ ਵੇਰਵਿਆਂ ਵਿੱਚ ਡੁਬਕੀ ਮਾਰੀਏ।

ਆਰਬਿਟਰ ਕਈ ਸੇਵਾਵਾਂ ਚਲਾਉਂਦਾ ਹੈ ਜੋ ਸਾਰੇ ਸਟੋਰੇਜ ਕੰਟਰੋਲਰਾਂ ਨੂੰ ਲਗਾਤਾਰ ਪੋਲ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਪੋਲ ਨਤੀਜਾ ਪਿਛਲੇ (ਉਪਲਬਧ/ਉਪਲਬਧ) ਤੋਂ ਵੱਖਰਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਇੱਕ ਛੋਟੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਆਰਬਿਟਰ 'ਤੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ।

ਆਉ ਆਰਬਿਟਰੇਟਰ ਦੇ ਕੰਮ ਦੇ ਤਰਕ ਨੂੰ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਵੇਖੀਏ.

ਕਦਮ 1: ਅਣਉਪਲਬਧਤਾ ਦਾ ਪਤਾ ਲਗਾਓ। ਇੱਕ ਸਟੋਰੇਜ਼ ਸਿਸਟਮ ਅਸਫਲਤਾ ਘਟਨਾ 5 ਸਕਿੰਟਾਂ ਦੇ ਅੰਦਰ ਇੱਕੋ ਸਟੋਰੇਜ ਸਿਸਟਮ ਦੇ ਦੋਵੇਂ ਕੰਟਰੋਲਰਾਂ ਤੋਂ ਪਿੰਗ ਦੀ ਗੈਰਹਾਜ਼ਰੀ ਹੈ।

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

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

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

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

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

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

ਇੱਕ ਸਕਿੰਟ ਇੰਤਜ਼ਾਰ ਕਰੋ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਜੇ ਮੈਟਰੋਕਲੱਸਟਰ ਨਾਲ ਸਭ ਕੁਝ ਇੰਨਾ ਵਧੀਆ ਹੈ, ਤਾਂ ਸਾਨੂੰ ਨਿਯਮਤ ਨਕਲ ਦੀ ਜ਼ਰੂਰਤ ਕਿਉਂ ਹੈ?

ਵਾਸਤਵ ਵਿੱਚ, ਹਰ ਚੀਜ਼ ਇੰਨੀ ਸਧਾਰਨ ਨਹੀਂ ਹੈ.

ਆਉ ਮੈਟਰੋਕਲੱਸਟਰ ਦੇ ਫਾਇਦਿਆਂ ਅਤੇ ਨੁਕਸਾਨਾਂ ਤੇ ਵਿਚਾਰ ਕਰੀਏ

ਇਸ ਲਈ, ਅਸੀਂ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਪਰੰਪਰਾਗਤ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਮੁਕਾਬਲੇ ਮੈਟਰੋਕਲੱਸਟਰ ਦੇ ਸਪੱਸ਼ਟ ਫਾਇਦੇ ਹਨ:

• ਪੂਰੀ ਆਟੋਮੇਸ਼ਨ, ਕਿਸੇ ਆਫ਼ਤ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਰਿਕਵਰੀ ਸਮਾਂ ਯਕੀਨੀ ਬਣਾਉਣਾ;
• ਇਹ ਸਭ ਹੈ :-).

ਅਤੇ ਹੁਣ, ਧਿਆਨ, ਨੁਕਸਾਨ:

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

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

ਮੈਟਰੋਕਲੱਸਟਰ ਦੀ ਯੋਜਨਾਬੰਦੀ

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

ਸਥਾਨ

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

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

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

ਜਿਵੇਂ ਕਿ ਆਰਬਿਟਰੇਟਰ ਤੋਂ ਪਹਿਲਾਂ ਦੇਰੀ ਲਈ (ਅਰਥਾਤ, ਤੀਜੀ ਸਾਈਟ ਅਤੇ ਪਹਿਲੇ ਦੋ ਵਿਚਕਾਰ), ਸਿਫ਼ਾਰਿਸ਼ ਕੀਤੀ ਦੇਰੀ ਥ੍ਰੈਸ਼ਹੋਲਡ 200 ਮਿਲੀਸਕਿੰਟ ਤੱਕ ਹੈ, ਯਾਨੀ, ਇੰਟਰਨੈਟ ਤੇ ਇੱਕ ਨਿਯਮਤ ਕਾਰਪੋਰੇਟ VPN ਕਨੈਕਸ਼ਨ ਢੁਕਵਾਂ ਹੈ।

ਸਵਿਚਿੰਗ ਅਤੇ ਨੈੱਟਵਰਕਿੰਗ

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

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

ਬੇਸ਼ੱਕ, ਹਰੇਕ ਹੋਸਟ ਨੂੰ ਆਪਟੀਕਲ ਕੋਰਡ ਨਾਲ ਕਿਸੇ ਹੋਰ ਡੇਟਾ ਸੈਂਟਰ ਨਾਲ ਜੋੜਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ; ਕੋਈ ਪੋਰਟ ਜਾਂ ਕੋਰਡ ਕਾਫ਼ੀ ਨਹੀਂ ਹੋਣਗੇ। ਇਹ ਸਾਰੇ ਕਨੈਕਸ਼ਨ ਈਥਰਨੈੱਟ 10G+ ਜਾਂ FibreChannel 8G+ ਸਵਿੱਚਾਂ ਰਾਹੀਂ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ (FC ਸਿਰਫ਼ IO ਲਈ ਮੇਜ਼ਬਾਨਾਂ ਅਤੇ ਸਟੋਰੇਜ ਸਿਸਟਮਾਂ ਨੂੰ ਕਨੈਕਟ ਕਰਨ ਲਈ ਹੈ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਚੈਨਲ ਵਰਤਮਾਨ ਵਿੱਚ ਸਿਰਫ਼ IP (ਈਥਰਨੈੱਟ 10G+) ਰਾਹੀਂ ਉਪਲਬਧ ਹੈ।

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

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

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

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

ਆਰਬਿਟਰ ਸੰਰਚਨਾ

ਆਰਬਿਟਰ ਨੂੰ ICMP ਅਤੇ SSH ਪ੍ਰੋਟੋਕੋਲ ਦੁਆਰਾ ਸਟੋਰੇਜ ਸਿਸਟਮ ਦੇ ਸਾਰੇ ਪ੍ਰਬੰਧਨ ਇੰਟਰਫੇਸਾਂ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਤੁਹਾਨੂੰ ਆਰਬਿਟਰ ਦੀ ਅਸਫਲ ਸੁਰੱਖਿਆ ਬਾਰੇ ਵੀ ਸੋਚਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਥੇ ਇੱਕ ਸੂਖਮਤਾ ਹੈ.

ਆਰਬਿਟਰ ਫੇਲਓਵਰ ਬਹੁਤ ਫਾਇਦੇਮੰਦ ਹੈ, ਪਰ ਲੋੜੀਂਦਾ ਨਹੀਂ ਹੈ। ਕੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਰੈਫਰੀ ਗਲਤ ਸਮੇਂ 'ਤੇ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ?

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

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

• ਇੱਕ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਹਾਈਪਰਵਾਈਜ਼ਰ 'ਤੇ ਆਰਬਿਟਰ ਨਾਲ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਲਾਂਚ ਕਰੋ, ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ ਸਾਰੇ ਬਾਲਗ ਹਾਈਪਰਵਾਈਜ਼ਰ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ;
• ਜੇ ਤੀਜੀ ਸਾਈਟ 'ਤੇ (ਇੱਕ ਰਵਾਇਤੀ ਦਫਤਰ ਵਿੱਚ) ਤੁਸੀਂ ਇੱਕ ਆਮ ਕਲੱਸਟਰ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਲਈ ਬਹੁਤ ਆਲਸੀ ਹੋ ਅਤੇ ਕੋਈ ਮੌਜੂਦਾ ਹਾਈਪਰਵੋਜ਼ਰ ਕਲੱਸਟਰ ਨਹੀਂ ਹੈ, ਤਾਂ ਅਸੀਂ ਆਰਬਿਟਰ ਦਾ ਇੱਕ ਹਾਰਡਵੇਅਰ ਸੰਸਕਰਣ ਪ੍ਰਦਾਨ ਕੀਤਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ 2U ਬਾਕਸ ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਹੈ ਜਿਸ ਵਿੱਚ ਦੋ ਆਮ. x-86 ਸਰਵਰ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਜੋ ਸਥਾਨਕ ਅਸਫਲਤਾ ਤੋਂ ਬਚ ਸਕਦੇ ਹਨ।

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

ਹੱਲ ਆਰਕੀਟੈਕਚਰ

ਉਪਰੋਕਤ ਲੋੜਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਆਮ ਹੱਲ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ।

ਗੰਭੀਰ ਓਵਰਲੋਡ ਤੋਂ ਬਚਣ ਲਈ LUNs ਨੂੰ ਦੋ ਸਾਈਟਾਂ ਵਿੱਚ ਬਰਾਬਰ ਵੰਡਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸਦੇ ਨਾਲ ਹੀ, ਜਦੋਂ ਦੋਵੇਂ ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਆਕਾਰ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਨਾ ਸਿਰਫ਼ ਦੋਹਰੀ ਵਾਲੀਅਮ (ਜੋ ਕਿ ਦੋ ਸਟੋਰੇਜ਼ ਸਿਸਟਮਾਂ 'ਤੇ ਇੱਕੋ ਸਮੇਂ ਡਾਟਾ ਸਟੋਰ ਕਰਨ ਲਈ ਜ਼ਰੂਰੀ ਹੈ), ਸਗੋਂ IOPS ਅਤੇ MB/s ਵਿੱਚ ਦੋਹਰੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਵੀ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਡਿਗਰੇਡੇਸ਼ਨ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ। ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਅਸਫਲਤਾ ਦੀ ਘਟਨਾ।

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

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

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

ਇੱਕ ਮੈਟਰੋਕਲਸਟਰ ਸਥਾਪਤ ਕਰਨਾ

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

ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲਈ ਵਰਚੁਅਲ IPs (VIPs) ਦੀ ਸੰਰਚਨਾ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ VIP ਕਿਸਮ ਦੀ ਚੋਣ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ - metrocluster ਲਈ।

ਅਸੀਂ ਦੋ LUNs ਲਈ ਦੋ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲਿੰਕ ਬਣਾਏ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਦੋ ਸਟੋਰੇਜ਼ ਸਿਸਟਮਾਂ ਵਿੱਚ ਵੰਡਿਆ: ਸਟੋਰੇਜ਼ ਸਿਸਟਮ 1 (ਮੈਟਰੋ ਲਿੰਕ) 'ਤੇ LUN ਟੈਸਟ ਪ੍ਰਾਇਮਰੀ, ਸਟੋਰੇਜ਼ ਸਿਸਟਮ 2 ਲਈ LUN ਟੈਸਟ 2 ਪ੍ਰਾਇਮਰੀ (METRO2 ਲਿੰਕ)।

ਉਹਨਾਂ ਲਈ, ਅਸੀਂ ਦੋ ਇੱਕੋ ਜਿਹੇ ਟੀਚੇ ਨੂੰ ਕੌਂਫਿਗਰ ਕੀਤਾ ਹੈ (ਸਾਡੇ ਕੇਸ ਵਿੱਚ iSCSI, ਪਰ FC ਵੀ ਸਮਰਥਿਤ ਹੈ, ਸੈੱਟਅੱਪ ਤਰਕ ਇੱਕੋ ਜਿਹਾ ਹੈ)।

ਸਟੋਰੇਜ਼ ਸਿਸਟਮ 1:

ਸਟੋਰੇਜ਼ ਸਿਸਟਮ 2:

ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਕਨੈਕਸ਼ਨਾਂ ਲਈ, ਹਰੇਕ ਸਟੋਰੇਜ਼ ਸਿਸਟਮ 'ਤੇ ਮੈਪਿੰਗ ਕੀਤੀ ਗਈ ਸੀ।

ਸਟੋਰੇਜ਼ ਸਿਸਟਮ 1:

ਸਟੋਰੇਜ਼ ਸਿਸਟਮ 2:

ਅਸੀਂ ਮਲਟੀਪਾਥ ਸਥਾਪਤ ਕੀਤਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਮੇਜ਼ਬਾਨ ਨੂੰ ਪੇਸ਼ ਕੀਤਾ ਹੈ।

ਇੱਕ ਸਾਲਸ ਸਥਾਪਤ ਕਰਨਾ

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

ਭਾਗ ਵਿੱਚ ਰਿਮੋਟ ਰੀਪਲੀਕੇਸ਼ਨ>> ਮੈਟਰੋਕਲਸਟਰ (ਕਿਸੇ ਵੀ ਕੰਟਰੋਲਰ 'ਤੇ)>> "ਸੰਰਚਨਾ ਕਰੋ" ਬਟਨ।

ਅਸੀਂ ਆਰਬਿਟਰ ਦਾ IP ਦਾਖਲ ਕਰਦੇ ਹਾਂ, ਨਾਲ ਹੀ ਦੋ ਰਿਮੋਟ ਸਟੋਰੇਜ ਕੰਟਰੋਲਰਾਂ ਦੇ ਕੰਟਰੋਲ ਇੰਟਰਫੇਸ ਵੀ.

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

ਅਸੀਂ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਕਿ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਚੱਲ ਰਹੀਆਂ ਹਨ।

ਇਹ ਮੈਟਰੋਕਲੱਸਟਰ ਸੈੱਟਅੱਪ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ।

ਕਰੈਸ਼ ਟੈਸਟ

ਸਾਡੇ ਕੇਸ ਵਿੱਚ ਕਰੈਸ਼ ਟੈਸਟ ਕਾਫ਼ੀ ਸਰਲ ਅਤੇ ਤੇਜ਼ ਹੋਵੇਗਾ, ਕਿਉਂਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਕਾਰਜਕੁਸ਼ਲਤਾ (ਸਵਿਚਿੰਗ, ਇਕਸਾਰਤਾ, ਆਦਿ) ਵਿੱਚ ਚਰਚਾ ਕੀਤੀ ਗਈ ਸੀ। ਆਖਰੀ ਲੇਖ. ਇਸ ਲਈ, ਮੈਟਰੋਕਲੱਸਟਰ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ, ਸਾਡੇ ਲਈ ਅਸਫਲਤਾ ਖੋਜ, ਸਵਿਚਿੰਗ ਅਤੇ ਰਿਕਾਰਡਿੰਗ ਨੁਕਸਾਨਾਂ ਦੀ ਅਣਹੋਂਦ (I/O ਸਟਾਪ) ਦੀ ਸਵੈਚਾਲਨ ਦੀ ਜਾਂਚ ਕਰਨਾ ਕਾਫ਼ੀ ਹੈ।

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

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

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

ਟੈਸਟ ਸਫਲਤਾਪੂਰਵਕ ਪੂਰਾ ਹੋਇਆ।

ਸੰਖੇਪ ਵਿੱਚ

AERODISK ਇੰਜਣ N-ਸੀਰੀਜ਼ ਸਟੋਰੇਜ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਮੈਟਰੋਕਲੱਸਟਰ ਦਾ ਵਰਤਮਾਨ ਲਾਗੂ ਕਰਨਾ ਉਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਿੱਥੇ IT ਸੇਵਾਵਾਂ ਲਈ ਡਾਊਨਟਾਈਮ ਨੂੰ ਖਤਮ ਕਰਨਾ ਜਾਂ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦੇ ਸੰਚਾਲਨ 24/7/365 ਨੂੰ ਘੱਟੋ-ਘੱਟ ਲੇਬਰ ਲਾਗਤਾਂ ਨਾਲ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ।

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

ਤੁਹਾਡਾ ਧੰਨਵਾਦ, ਅਸੀਂ ਇੱਕ ਲਾਭਕਾਰੀ ਚਰਚਾ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਾਂ।

ਸਰੋਤ: www.habr.com