ਪ੍ਰਤੀ-ਸਾਈਟ ਵੱਖਰਾਪਣ

ਹਰੇਕ ਸਾਈਟ ਆਪਣੇ ਪਿੰਜਰੇ ਵਿੱਚ, ਤਾਂ ਜੋ ਇੱਕ ਮਾੜਾ ਗੁਆਂਢੀ ਸਿਰਫ਼ ਇੱਕ ਮਾੜਾ ਗੁਆਂਢੀ ਹੀ ਰਹੇ।

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

ਆਪਣੀ ਕੰਟੇਨਮੈਂਟ ਸੀਮਾ ਨਾਲ ਘਿਰੀ ਇੱਕ ਸਿੰਗਲ ਸਾਈਟ, ਜੋ ਆਪਣੇ ਗੁਆਂਢੀਆਂ ਤੋਂ ਵੱਖ ਹੈ।
  • 7,00,000+ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਹੋਸਟ ਕੀਤੀਆਂ ਸਾਈਟਾਂ
  • ਪ੍ਰਤੀ-ਸਾਈਟਸੀਪੀਯੂ, ਰੈਮ, ਆਈਓ, ਆਈਓਪੀਐੱਸ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਸੀਮਾਵਾਂ
  • 99.99%ਅੱਪਟਾਈਮ ਭਰੋਸਾ
  • ਸ਼ਾਮਲ ਹੈਹਰੇਕ ਪਲਾਨ 'ਤੇ ਆਈਸੋਲੇਸ਼ਨ ਬੇਸਲਾਈਨ

ਸੰਰਚਨਾ ਫ਼ਾਈਲ ਵਿੱਚ ਨਹੀਂ, ਕਰਨਲ ਪੱਧਰ 'ਤੇ ਅਲੱਗ-ਥਲੱਗਤਾ

ਵਰਕਰ ਫਲੀਟ CloudLinux OS ਚਲਾਉਂਦੀ ਹੈ, ਜੋ ਮਲਟੀ-ਟੈਨੈਂਸੀ ਨੂੰ ਕਰਨਲ ਵਿੱਚ ਹੇਠਾਂ ਧੱਕਦੀ ਹੈ। ਹਰੇਕ ਸਾਈਟ ਨੂੰ ਇੱਕ ਲਾਈਟਵੇਟ ਵਰਚੁਅਲ ਇਨਵਾਇਰਨਮੈਂਟ — ਇੱਕ LVE — ਮਿਲਦਾ ਹੈ ਜੋ ਕਿ ਸਿਰਫ਼ ਇੱਕ ਰਸਮੀ ਸਮਝੌਤੇ ਦੀ ਬਜਾਏ ਇੱਕ ਪੱਕੀ ਹੱਦਬੰਦੀ ਹੁੰਦਾ ਹੈ। ਕੋਈ ਸਾਈਟ ਆਪਣੇ ਕੇਜ ਦੇ ਅੰਦਰ ਜੋ ਕੁਝ ਵੀ ਕਰਦੀ ਹੈ, ਉਸਦਾ ਖ਼ਰਚਾ ਕਿਸੇ ਹੋਰ ਦੇ ਬਜਟ ਵਿੱਚੋਂ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।

ਪ੍ਰਤੀ-ਸਾਈਟ ਸਖ਼ਤ ਸਰੋਤ ਉੱਚ-ਸੀਮਾਵਾਂ

LVE ਹਰੇਕ ਸਾਈਟ ਲਈ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ CPU, RAM, IO, IOPS, ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ entry-processes ਨੂੰ ਸੀਮਤ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਸਾਈਟ ਆਪਣੀ ਅਧਿਕਤਮ ਸੀਮਾ ਨੂੰ ਪਾਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਇਸਦੇ ਆਪਣੇ cage ਦੇ ਅੰਦਰ ਹੀ ਥ੍ਰੋਟਲ (ਸੀਮਤ) ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ — ਨੁਕਸ ਉਸ ਸਾਈਟ ਦੇ ਵਿਰੁੱਧ ਦਰਜ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀਆਂ ਸਾਈਟਾਂ ਬਿਨਾਂ ਕਿਸੇ ਪ੍ਰਭਾਵ ਦੇ ਆਮ ਵਾਂਗ ਚੱਲਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ।

ਬੇਕਾਬੂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ, ਉਹਨਾਂ ਦਾ ਪਿੱਛਾ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ

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

ਹਮਲੇ ਦਾ ਟ੍ਰੈਫਿਕ ਪ੍ਰਤੀ ਸਾਈਟ ਸੀਮਤ ਹੈ

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

ਸਰੋਤ ਦੀਆਂ ਖਾਮੀਆਂ ਹੈਰਾਨੀ ਨਹੀਂ, ਸਗੋਂ ਸੰਕੇਤ ਬਣ ਜਾਂਦੀਆਂ ਹਨ

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

ਤੁਹਾਡਾ ਆਪਣਾ ਫ਼ਾਈਲ ਸਿਸਟਮ ਦ੍ਰਿਸ਼

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

CageFS ਦੇ ਅਧੀਨ, ਇੱਕ ਕਿਰਾਏਦਾਰ ਸਿਰਫ਼ ਆਪਣੀਆਂ ਫ਼ਾਈਲਾਂ ਅਤੇ ਸਿਸਟਮ ਬਾਇਨਰੀਆਂ ਦਾ ਇੱਕ ਨਿਊਨਤਮ, ਸਵੱਛ ਕੀਤਾ ਸੈੱਟ ਦੇਖ ਸਕਦਾ ਹੈ — ਅਤੇ ਹੋਰ ਕਿਰਾਏਦਾਰਾਂ, ਹੋਰ ਕਿਰਾਏਦਾਰਾਂ ਦੀਆਂ ਸਾਈਟਾਂ, ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਸਿਸਟਮ ਫ਼ਾਈਲਾਂ ਨੂੰ ਨਹੀਂ ਦੇਖ ਸਕਦਾ। ਸ਼ੇਅਰਡ-ਹੋਸਟਿੰਗ ਦਾ ਆਮ ਅਸਫ਼ਲਤਾ ਮੋਡ, ਜਿੱਥੇ ਇੱਕ ਸਮਝੌਤਾ ਕੀਤਾ ਖਾਤਾ ਸਰਵਰ 'ਤੇ ਹਰ ਦੂਜੇ ਖਾਤੇ ਨੂੰ ਦੇਖਣ ਦੀ ਸਥਿਤੀ ਬਣ ਜਾਂਦਾ ਹੈ, ਨੂੰ ਕਰਨਲ ਪੱਧਰ 'ਤੇ ਬੰਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

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

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

ਡਾਟਾਬੇਸ ਵੀ ਅਲੱਗ ਰੱਖਿਆ ਗਿਆ ਹੈ — ਆਮ ਤੌਰ 'ਤੇ ਹੋਸਟਿੰਗ ਇੱਥੇ ਹੀ ਰੌਲੇ-ਰੱਪੇ ਵਾਲੀ ਹੁੰਦੀ ਹੈ

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

MySQL Governor

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

WordPress ਵਰਕਲੋਡਾਂ ਲਈ MariaDB

ਇਹ ਫਲੀਟ MariaDB (ਜਾਂ Percona) ਚਲਾਉਂਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਡਿਫੌਲਟ ਵਜੋਂ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਣ ਦੀ ਬਜਾਏ WordPress ਵਰਕਲੋਡਾਂ ਲਈ ਚੁਣਿਆ ਗਿਆ ਹੈ, ਜਿਸ ਦੇ ਸਿਖਰ 'ਤੇ Governor ਹਰੇਕ ਕਿਰਾਏਦਾਰ ਲਈ ਨਿਰਪੱਖਤਾ ਪਰਤ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਅੱਗੇ Redis ਆਬਜੈਕਟ ਕੈਸ਼

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

ਪ੍ਰਤੀ-ਸਾਈਟ PHP, ਮਜ਼ਬੂਤ ਕੀਤਾ ਹੋਇਆ

CloudLinux alt-PHP ਹਰੇਕ ਸਾਈਟ ਨੂੰ ਆਪਣਾ PHP ਸੰਸਕਰਣ ਚੋਣਕਾਰ, ਆਪਣੇ ਐਕਸਟੈਂਸ਼ਨ (imagick, gd, redis ਅਤੇ ਬਾਕੀ) ਅਤੇ ਆਪਣੀਆਂ ਸੁਰੱਖਿਅਤ ਸੈਟਿੰਗਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ — ਜਿਸ ਵਿੱਚ LSAPI ਵਰਕਰ ਉਸ ਸਾਈਟ ਦੀਆਂ LVE ਸੀਮਾਵਾਂ ਦੁਆਰਾ ਬੰਨ੍ਹੇ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਜੋ PHP ਸਮਕਾਲੀਤਾ ਪਿੰਜਰੇ ਵਿੱਚੋਂ ਨਿਕਲਣ ਦੀ ਬਜਾਏ ਉਸਦਾ ਹਿੱਸਾ ਬਣੇ।

ਅਸਫਲਤਾ ਦਰਜਾਬੰਦ, ਉਲਟਾਉਣਯੋਗ ਅਤੇ ਸਮਝਾਈ ਗਈ ਹੈ

ਅਲੱਗਤਾ ਇਹ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਕੋਈ ਸਮੱਸਿਆ ਕਿੰਨੀ ਦੂਰ ਤੱਕ ਫੈਲਦੀ ਹੈ। ਲਾਗੂਕਰਨ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਅੱਗੇ ਕੀ ਹੋਵੇਗਾ। ਅਸੀਂ ਸਿੱਧੇ ਚਾਲੂ/ਬੰਦ ਮੁਅੱਤਲੀ ਨੂੰ ਇੱਕ ਸਟੇਟ ਮਸ਼ੀਨ ਨਾਲ ਬਦਲ ਦਿੱਤਾ ਹੈ, ਜੋ ਟਿਕਾਊ ਵਰਕਫਲੋ ਦੁਆਰਾ ਸੰਚਾਲਿਤ ਹੈ ਅਤੇ LiteSpeed, LVE ਅਤੇ Imunify ਰਾਹੀਂ ਵਰਕਰ ਉੱਤੇ ਲਾਗੂ ਕੀਤੀ ਗਈ ਹੈ।

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

ਦੋਵਾਂ ਉਤਪਾਦ ਲਾਈਨਾਂ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀ ਆਈਸੋਲੇਸ਼ਨ — ਅਤੇ ਜਦੋਂ ਤੁਹਾਨੂੰ ਲੋੜ ਹੋਵੇ ਤਾਂ ਇੱਕ ਵਧੇਰੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਪੱਧਰ

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

Footprint-Free ਹੋਸਟਿੰਗ

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

Zinn® Managed WordPress

ਪ੍ਰਬੰਧਿਤ WordPress, WooCommerce, PHP, ਸਟੈਟਿਕ ਅਤੇ Node ਸਾਈਟਾਂ ਨੂੰ ਉਹੀ ਅਲੱਗ ਕੀਤੇ ਵਾਤਾਵਰਨ (cages) ਅਤੇ ਪੂਰੀ ਸਵੈ-ਸੇਵਾ ਮਿਲਦੀ ਹੈ — ਤੁਹਾਡਾ ਆਪਣਾ PHP ਸੰਸਕਰਣ ਅਤੇ ਐਕਸਟੈਂਸ਼ਨਾਂ, Redis ਆਬਜੈਕਟ ਕੈਸ਼, ਸਟੇਜਿੰਗ ਅਤੇ ਪੁਸ਼-ਟੂ-ਲਾਈਵ।

ਪ੍ਰੀਮੀਅਮ ਵਿਕਲਪ ਵਜੋਂ ਪ੍ਰਤੀ-ਸਾਈਟ ਕੰਟੇਨਰ

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

ਸ਼ਾਮਲ ਹੈ, ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਵੇਚਿਆ ਨਹੀਂ ਗਿਆ

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

ਇੱਥੇ ਆਈਸੋਲੇਸ਼ਨ ਕਦੇ ਵੀ ਵਿਕਲਪਿਕ ਕਿਉਂ ਨਹੀਂ ਹੁੰਦੀ

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

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

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

ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਸਵਾਲ

ਕੀ ਕਿਸੇ ਹੋਰ ਗਾਹਕ ਦੀ ਸਾਈਟ ਮੇਰੀ ਸਾਈਟ ਨੂੰ ਹੌਲੀ ਕਰ ਸਕਦੀ ਹੈ?

ਇਸ ਨੂੰ ਰੋਕਣ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਆਈਸੋਲੇਸ਼ਨ ਤਿਆਰ ਕੀਤੀ ਗਈ ਹੈ। LVE ਪ੍ਰਤੀ ਸਾਈਟ CPU, RAM, IO, IOPS ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸੀਮਤ ਕਰਦਾ ਹੈ, MySQL Governor ਪ੍ਰਤੀ ਸਾਈਟ ਡਾਟਾਬੇਸ ਵਰਤੋਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ LSAPI ਵਰਕਰ ਸਾਈਟ ਦੇ ਆਪਣੇ ਪਿੰਜਰੇ (cage) ਦੁਆਰਾ ਸੀਮਤ ਹੁੰਦੇ ਹਨ — ਤਾਂ ਜੋ ਕਿਸੇ ਗੁਆਂਢੀ ਸਾਈਟ ਦੇ ਟ੍ਰੈਫਿਕ ਵਿੱਚ ਵਾਧਾ ਜਾਂ ਭਾਰੀ ਪੁੱਛਗਿੱਛ ਦਾ ਬੋਝ ਤੁਹਾਡੀ ਸੀਮਾ ਦੀ ਬਜਾਏ ਉਹਨਾਂ ਦੀ ਅਧਿਕਤਮ ਸੀਮਾ ਅਨੁਸਾਰ ਨਿਯੰਤਰਿਤ ਹੋਵੇ। ਹਰੇਕ ਨੁਕਸ ਪ੍ਰਤੀ ਸਾਈਟ ਲੌਗ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਨੀਤੀ ਇੰਜਣ ਆਪਣੇ ਆਪ ਰੌਲਾ ਪਾਉਣ ਵਾਲੀ ਸਾਈਟ ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਸਖ਼ਤ ਕਰ ਸਕਦਾ ਹੈ।

ਜੇਕਰ ਉਸੇ ਸਰਵਰ 'ਤੇ ਕੋਈ ਸਾਈਟ ਹੈਕ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਕੀ ਮੇਰੀ ਸਾਈਟ ਖ਼ਤਰੇ ਵਿੱਚ ਹੈ?

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

ਕੀ ਆਈਸੋਲੇਸ਼ਨ ਸ਼ਾਮਲ ਹੈ, ਜਾਂ ਇਸਦਾ ਵਾਧੂ ਖ਼ਰਚਾ ਹੈ?

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

ਜੇਕਰ ਮੇਰੀ ਸਾਈਟ ਆਪਣੀਆਂ ਸਰੋਤ ਸੀਮਾਵਾਂ ਨੂੰ ਪਾਰ ਕਰ ਜਾਂਦੀ ਹੈ ਤਾਂ ਕੀ ਹੋਵੇਗਾ?

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

ਕੀ ਮੁਅੱਤਲ ਕੀਤੀ ਸਾਈਟ ਸਿਰਫ਼ ਖਾਲੀ ਹੋ ਜਾਂਦੀ ਹੈ?

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

ਕੀ ਮੈਂ ਆਪਣਾ ਖੁਦ ਦਾ PHP ਸੰਸਕਰਣ ਅਤੇ ਐਕਸਟੈਂਸ਼ਨਾਂ ਚੁਣ ਸਕਦਾ ਹਾਂ?

Zinn® Managed WordPress 'ਤੇ, ਹਾਂ — CloudLinux alt-PHP ਹਰੇਕ ਸਾਈਟ ਨੂੰ ਆਪਣਾ PHP ਸੰਸਕਰਣ ਚੋਣਕਾਰ, imagick, gd ਅਤੇ redis ਵਰਗੇ ਆਪਣੇ ਐਕਸਟੈਂਸ਼ਨ, ਅਤੇ ਆਪਣੀਆਂ ਮਜ਼ਬੂਤ ਕੀਤੀਆਂ ਸੈਟਿੰਗਾਂ ਦਿੰਦਾ ਹੈ, ਜੋ ਸਾਰੇ ਉਸ ਸਾਈਟ ਦੀਆਂ LVE ਸੀਮਾਵਾਂ ਦੁਆਰਾ ਬੰਨੇ ਹੋਏ ਹਨ। Footprint-Free ਹੋਸਟਿੰਗ ਜਾਣਬੁੱਝ ਕੇ ਪ੍ਰਤੀ-ਸਾਈਟ ਵਧੇਰੇ ਮਾਨਕੀਕ੍ਰਿਤ, ਲਾਕ-ਡਾਊਨ ਕੌਂਫਿਗਰੇਸ਼ਨ ਚਲਾਉਂਦੀ ਹੈ, ਕਿਉਂਕਿ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿਭਿੰਨਤਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਫੁੱਟਪ੍ਰਿੰਟ (footprint) ਹੈ।

ਕੀ ਸਾਂਝੇ-ਕਰਨਲ ਮਾਡਲ ਨਾਲੋਂ ਵਧੇਰੇ ਮਜ਼ਬੂਤ ਅਲੱਗਤਾ ਵਿਕਲਪ ਹੈ?

ਹਾਂ। CloudLinux LVE ਅਤੇ CageFS ਦੋਵਾਂ ਉਤਪਾਦ ਲਾਈਨਾਂ ਵਿੱਚ ਘਣਤਾ-ਅਨੁਕੂਲਿਤ ਡਿਫੌਲਟ ਹੈ। ਵਧੇਰੇ ਸਖ਼ਤ ਸੀਮਾ ਦੀ ਲੋੜ ਵਾਲੇ ਵਰਕਲੋਡਾਂ ਲਈ, ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ-ਡਰਾਈਵਰ ਰੂਪ ਵਜੋਂ ਪ੍ਰਤੀ-ਸਾਈਟ ਪੂਰਾ ਕੰਟੇਨਰ ਅਲੱਗਤਾ ਦੀ ਪੇਸ਼ਕਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ — ਵੱਖਰੇ ਪਲੇਸਮੈਂਟ ਦੇ ਨਾਲ ਉਹੀ ਇੰਜਣ ਅਤੇ ਨਿਯੰਤਰਣ ਪਲੇਨ, ਜੋ ਮਜ਼ਬੂਤ ​​ਵੱਖਰੇਵੇਂ ਲਈ ਓਵਰਹੈੱਡ ਦਾ ਵਪਾਰ ਕਰਦਾ ਹੈ।

ਕੀ ਮੈਂ ਵਚਨਬੱਧ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਅਜ਼ਮਾ ਸਕਦਾ ਹਾਂ?

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

ਵੇਖੋ ਕਿ ਤੁਹਾਡੇ ਆਪਣੇ ਲੋਡ ਅਧੀਨ ਪਿੰਜਰੇ ਕਿਵੇਂ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ

Footprint-Free ਹੋਸਟਿੰਗ 'ਤੇ ਬਿਨਾਂ ਕਾਰਡ ਦੇ 14-ਦਿਨਾਂ ਦਾ ਟ੍ਰਾਇਲ ਸ਼ੁਰੂ ਕਰੋ — 5 ਸਾਈਟਾਂ ਤੱਕ, ਭੁਗਤਾਨ ਦੇ ਵੇਰਵਿਆਂ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ, ਕੋਈ ਵਚਨਬੱਧਤਾ ਨਹੀਂ। ਕਰਨਲ-ਪੱਧਰੀ ਆਈਸੋਲੇਸ਼ਨ, ਕਿਰਿਆਸ਼ੀਲ WAF ਅਤੇ ਮਾਲਵੇਅਰ ਸਕੈਨਿੰਗ ਪਹਿਲੇ ਡਿਪਲਾਏ ਤੋਂ ਹੀ ਸ਼ਾਮਲ ਹਨ।

ਮੁਫ਼ਤ ਸ਼ੁਰੂ ਕਰੋ