Shared hosting বনাম VPS: আপনার জন্য কোনটি সঠিক?

Shared hosting বনাম VPS: সংক্ষিপ্ত উত্তর

Shared hosting বনাম VPS গতির কোনো প্রশ্ন নয়। Shared hosting-এ আপনি এমন একটি মেশিনে অ্যাকাউন্ট ভাড়া নেন যা অন্য কেউ কনফিগার করে, প্যাচ দেয় এবং গ্রাহকদের মধ্যে ভাগ করে দেয়। একটি unmanaged VPS (virtual private server)-এ আপনি root access সহ একটি সম্পূর্ণ অপারেটিং সিস্টেম ভাড়া নেন, তাই আপনি যা খুশি ইনস্টল করতে পারেন এবং নিজের করা ভুলগুলো আপনাকেই ঠিক করতে হয়।

মূলত তিনটি বিষয়ে পার্থক্য থাকে। আপনার root access আছে কি নেই, সেটিই প্রথম। আপনার মেমরি অ্যালোকেশন এবং গ্যারান্টি আপনার প্ল্যানের ওপর নির্ভর করে। আর মাঝরাতে সার্ভার সাড়া দেওয়া বন্ধ করলে, হয় হোস্ট কোম্পানি তা ঠিক করবে, নয়তো আপনাকে করতে হবে। ফিচারের তালিকায় যা কিছু দেখেন, তা এই তিনটি বিষয়েরই ফলাফল।

আপনার সাইট যদি কেবল কিছু পেজ, ইমেজ এবং একটি কন্টাক্ট ফর্ম নিয়ে হয়, তবে অনেক সাইটের জন্যই Shared hosting সঠিক সমাধান। আপনার সাইটের যদি এমন কোনো প্রোগ্রামের প্রয়োজন হয় যা কেউ ভিজিট না করলেও ব্যাকগ্রাউন্ডে চলতে থাকে, তবে VPS বেছে নেওয়ার আগে দেখে নিন আপনার shared host এমন persistent service সমর্থন করে কি না।

শেয়ারড হোস্টিং আপনাকে আসলে যা প্রদান করে

একটি Linux সার্ভার একই সাথে অনেক গ্রাহকের অ্যাকাউন্ট পরিচালনা করে। প্রতিটি অ্যাকাউন্ট হলো একটি হোম ডিরেক্টরি, যার সাথে একটি ডকুমেন্ট রুট, একটি ডাটাবেস এবং একটি মেইলবক্স থাকে। একটি মাত্র ওয়েব সার্ভার, সাধারণত Apache বা LiteSpeed, সার্ভারের প্রতিটি সাইটকে সেবা প্রদান করে। আপনি একটি কন্ট্রোল প্যানেল পান এবং কিছু হোস্ট শেল প্রম্পটও অফার করে। আপনি root অ্যাক্সেস পান না, তবে কিছু প্রোভাইডার আপনার হোম ডিরেক্টরিতে সফটওয়্যার ইনস্টল করার, অনুমোদিত পোর্ট ব্যবহারের এবং ব্যাকগ্রাউন্ড সার্ভিস চালানোর অনুমতি দেয়।

অনেক শেয়ারড হোস্ট CloudLinux চালায়, যা প্রতিটি অ্যাকাউন্টকে নিজস্ব হালকা ওজনের কন্টেইনারে রাখে। এতে প্রসেসর টাইম, মেমোরি, ডিস্ক I/O, প্রসেসের সংখ্যা এবং এন্ট্রি প্রসেসের সংখ্যার ওপর সীমাবদ্ধতা থাকে। প্রতিটি সীমাবদ্ধতা লঙ্ঘনের ফলাফল ভিন্ন। প্রসেসর বা I/O সীমা অতিক্রম করলে আপনার সাইট ধীরগতিতে সাড়া দেয়; এটি সাইটকে অচল করে দেয় না। মেমোরি বা প্রসেস সীমা অতিক্রম করলে সাধারণত 500 এবং 503 এরর দেখা দেয়। Apache-এর ক্ষেত্রে, 508 Resource Limit Reached শিরোনামের এরর পেজটি এন্ট্রি-প্রসেস সীমার কারণে আসে; LiteSpeed এন্ট্রি প্রসেসগুলো ভিন্নভাবে পরিচালনা করে। প্রতিটি ক্ষেত্রেই এটি আপনার নিজের অ্যাকাউন্টের সীমাবদ্ধতায় পৌঁছানোর কারণে ঘটে, কোনো প্রতিবেশী আপনার অংশ দখল করে নেওয়ার কারণে নয়।

এই বিনিময়টি সচেতনভাবে করা হয়। আপনি নিয়ন্ত্রণ ত্যাগ করেন এবং বিনিময়ে হোস্ট কার্নেল প্যাচ করে এবং সমর্থিত সফটওয়্যার রক্ষণাবেক্ষণ করে; সার্টিফিকেট রিনিউয়াল এবং ব্যাকআপ শিডিউল আপনার প্ল্যানের ওপর নির্ভর করে। অনেক সাইটের জন্য এটি একটি ভালো বিনিময়।

একটি VPS আপনাকে আসলে যা প্রদান করে

একটি VPS হলো একটি হোস্ট সার্ভারে চলমান একটি ভার্চুয়াল মেশিন। KVM-এর অধীনে, আপনার ইনস্ট্যান্সটি নিজস্ব কার্নেল বুট করে এবং এর নিজস্ব IP অ্যাড্রেস, নিজস্ব ফায়ারওয়াল এবং নিজস্ব init সিস্টেম থাকে। root অ্যাক্সেসসহ একটি unmanaged Linux VPS-এ, sudo কাজ করে। একটি Debian বা Ubuntu ইনস্টলেশনে, apt install কাজ করে। systemd-এর মাধ্যমে আপনি যে প্রোগ্রামটি শুরু করেন তা লগ আউট করার পরেও চলতে থাকে, এবং যথাযথ রিস্টার্ট ও বুট কনফিগারেশনের মাধ্যমে এটি ক্র্যাশের পরে পুনরায় চালু হয় এবং রিবুটের পরে ফিরে আসে।

এই root অ্যাক্সেসের কারণেই মেশিনের নিরাপত্তা নিশ্চিত করার দায়িত্ব আপনার। অন্য কেউ এটি পর্যবেক্ষণ করছে না। VPS-এ মানুষ যা যা চালায় তার পরিসর ঠিক এই কারণেই অনেক বিস্তৃত: একটি Linux সার্ভার যা কিছু করতে পারে, এই বক্সটিও তা-ই করতে সক্ষম।

পার্থক্য 1: root access এবং এটি যা যা উন্মুক্ত করে

Root আপনাকে অপারেটিং সিস্টেমের ওপর পূর্ণ নিয়ন্ত্রণ দেয়। এটি থাকলে আপনি ডিস্ট্রিবিউশন থেকে যেকোনো প্যাকেজ ইনস্টল করতে পারেন, যেকোনো পোর্টে বাইন্ড করতে পারেন, systemd unit লিখতে পারেন, মেশিনের প্রতিটি লগ পড়তে পারেন এবং sysctl ব্যবহার করে কার্নেল সেটিংস পরিবর্তন করতে পারেন। এটি ছাড়া, প্যানেলই সবসময় একমাত্র সীমাবদ্ধতা নয়: alwaysdata ad_install_pecl ব্যবহার করে অতিরিক্ত PHP extension ইনস্টল করার সুবিধা দেয়।

একটি VPS-এ আপনি সবসময় মেশিনকে জিজ্ঞাসা করতে পারেন কোন পোর্টগুলো লিসেনিং মোডে আছে:

ss -ltnp

প্রতিটি সকেট সারি একটি TCP লিসেনার প্রদর্শন করে; প্রসেস সংক্রান্ত বিস্তারিত তথ্য আপনার অনুমতির ওপর নির্ভর করে, তাই কোনো সার্ভিস যদি TCP-তে লিসেন করার কথা থাকলেও তা চালু হতে ব্যর্থ হয়, তবে সেটি তালিকায় দেখা যাবে না। শেয়ারড হোস্টিংয়ে, সকেট সংক্রান্ত তথ্য দেখার সুযোগ এবং নিজস্ব লিসেনার চালানোর অনুমতি প্রদানকারীর ওপর নির্ভর করে, যদিও হোস্ট পোর্ট 80 এবং 443 নিয়ন্ত্রণ করে।

পার্থক্য 2: বরাদ্দকৃত মেমরি বনাম ধার করা মেমরি

শেয়ার্ড হোস্টিং এই ধারণার ওপর ভিত্তি করে বিক্রি করা হয় যে, খুব কম সংখ্যক অ্যাকাউন্ট একই সময়ে ব্যস্ত থাকে। মেশিনের মেমরি একটি পুলের মতো, এবং আপনার অ্যাকাউন্টের অংশটি একটি রিজার্ভেশন বা সংরক্ষিত সীমার পরিবর্তে একটি সর্বোচ্চ সীমা মাত্র। CloudLinux-এ, ফিজিক্যাল-মেমরি লিমিট অতিক্রম করলে প্রসেসগুলো বন্ধ হয়ে যায় এবং ভিজিটররা 500 বা 503 এরর পেতে পারে।

একটি VPS-এ, free -m আপনার গেস্টের কাছে দৃশ্যমান মেমরি রিপোর্ট করে, এটি কোনো অপরিবর্তনীয় ফিজিক্যাল-মেমরি রিজার্ভেশনের প্রমাণ নয়। হোস্ট চাইলে বেলুনিং (ballooning)-এর মাধ্যমে গেস্ট মেমরি পুনরুদ্ধার করতে পারে; আপনার প্ল্যানে এটি অনুমোদিত কি না তা প্রোভাইডারের রিসোর্স গ্যারান্টির ওপর নির্ভর করে।

শেয়ার্ড-CPU VPS প্ল্যানে প্রসেসর টাইম আরেকটি শেয়ার্ড রিসোর্স, এবং আপনি নিজেই স্টিল টাইম (steal time) পরিমাপ করতে পারেন:

vmstat 1 5

st কলামটি হলো স্টিল টাইম: আপনার ভার্চুয়াল প্রসেসর যখন কাজ করার জন্য প্রস্তুত ছিল, কিন্তু ফিজিক্যাল কোরটি অন্য কোনো গেস্টকে দেওয়া হয়েছিল, সেই সময়ের অংশ। ওভারসাবস্ক্রিপশন প্রমাণের জন্য কোনো সর্বজনীন স্বাভাবিক শতাংশ বা থ্রেশহোল্ড নেই; তবে দীর্ঘস্থায়ী স্টিল টাইম এমন একটি তথ্য যা আপনি সাপোর্ট টিকিটে উল্লেখ করতে পারেন। vmstat-এর সাধারণ রিডিংয়ের জন্য প্রাসঙ্গিক /proc ফাইলগুলোতে অ্যাক্সেস প্রয়োজন, রুট অ্যাক্সেসের প্রয়োজন নেই, এবং একটি শেয়ার্ড হোস্ট এই দৃশ্যমানতা সীমাবদ্ধ করতে পারে। স্টোরেজও একটি রিসোর্স যা পরীক্ষা করা উচিত, আর এই কারণেই একটি VPS প্ল্যানের পেছনের ডিস্কের ধরন গুরুত্বপূর্ণ, এবং বিক্রয়ের পৃষ্ঠায় বিশ্বাস করার পরিবর্তে প্রথম সপ্তাহে একটি নতুন VPS নিজে পরিমাপ করা বুদ্ধিমানের কাজ।

পার্থক্য 3: কোনো সমস্যা হলে দায় কার

Shared hosting-এ হোস্ট কোম্পানি অপারেটিং সিস্টেম, ওয়েব সার্ভার এবং সমর্থিত PHP বিল্ডগুলো পরিচালনা করে; সার্টিফিকেট এবং ব্যাকআপের সুবিধা আপনার প্ল্যানের ওপর নির্ভর করে। সার্ভার রেসপন্স করা বন্ধ করে দিলে আপনি একটি সাপোর্ট টিকিট খুলবেন; এরপর কী হবে তা হোস্টের সাপোর্ট ব্যবস্থার ওপর নির্ভর করে। এর বিনিময়ে আপনাকে যা মেনে নিতে হয় তা হলো: সমর্থিত পরিবেশের বাইরের কোনো সফটওয়্যার হোস্টের ইন্সটলেশন এবং সার্ভিস পলিসির সাথে সামঞ্জস্যপূর্ণ হতে হবে।

একটি unmanaged VPS-এ প্রোভাইডার শুধু হাইপারভাইজার, নেটওয়ার্ক এবং পাওয়ারের মালিক। কার্নেল থেকে শুরু করে ওপরের সবকিছু আপনার দায়িত্ব। সিকিউরিটি আপডেট, ফায়ারওয়াল, ব্যাকআপ, সার্টিফিকেট রিনিউয়াল এবং মনিটরিং—সবই আপনাকে করতে হবে। আপনার ওয়েব সার্ভার কনফিগারেশন ডিবাগ করার জন্য সাপোর্ট টিম সার্ভারে লগইন করবে না। তাই প্রথম দিন থেকেই প্রস্তুতি নিন: নতুন VPS-এ প্রথম দশ মিনিট, এরপর আপনার বোধগম্য একটি ফায়ারওয়াল, স্বয়ংক্রিয় সিকিউরিটি আপডেট এবং এমন ব্যাকআপ যা আপনি অন্তত একবার রিস্টোর করে দেখেছেন।

কখন shared hosting সঠিক সমাধান

একটি ব্রোশিওর সাইট এর সবচেয়ে স্পষ্ট উদাহরণ: কিছু পেজ, ছবি, একটি কন্টাক্ট ফর্ম, সম্ভবত একটি ক্যাশিং প্লাগইনসহ WordPress এবং প্ল্যানের রিসোর্স লিমিটের মধ্যে থাকা ট্রাফিক। কোনো ব্যাকগ্রাউন্ড জব নেই। কোনো অস্বাভাবিক রানটাইম নেই। রিকোয়েস্টের মাঝে মেমরিতে ধরে রাখতে হয় এমন কিছু নেই। Shared hosting এই ধরনের সাইটের জন্য উপযুক্ত এবং সার্ভার রক্ষণাবেক্ষণের দায়িত্ব তাদের ওপর ছেড়ে দেয় যারা এটি পূর্ণকালীন পেশা হিসেবে করে; দাম যাচাই করে দেখুন কারণ এটি সবসময় VPS-এর চেয়ে সস্তা হয় না। এটিকে VPS-এ স্থানান্তর করলে কোনো বাড়তি সুবিধা পাওয়া যায় না, বরং এমন একটি কাজের দায়িত্ব ঘাড়ে আসে যা আগে ছিল না।

দ্বিতীয় আরেকটি ক্ষেত্র আছে যা খুব একটা গুরুত্ব পায় না। যদি আপনার টিমের কেউ লগ ফাইল পড়তে বা apt upgrade চালাতে আগ্রহী না হন, তবে shared hosting-ই নিরাপদ পছন্দ। একটি আনপ্যাচড VPS যেখানে ডাটাবেস পোর্ট খোলা থাকে, তা একজন পেশাদার দ্বারা পরিচালিত shared account-এর চেয়ে অনেক বেশি ঝুঁকিপূর্ণ। নিয়ন্ত্রণ তখনই একটি সুবিধা যখন কেউ তা ব্যবহার করে।

লক্ষণ 1: আপনার এমন একটি প্রোগ্রাম প্রয়োজন যা সবসময় চলতে থাকে

একটি daemon হলো এমন একটি প্রোগ্রাম যা মেমরিতে অবস্থান করে এবং কাজের অপেক্ষায় থাকে: যেমন একটি API, চ্যাট বট, কিউ ওয়ার্কার বা গেম সার্ভার। শেয়ার্ড হোস্টিংয়ের নিয়ম ভিন্ন হয়: DreamHost তাদের শেয়ার্ড প্ল্যানে দীর্ঘস্থায়ী প্রসেস চালানোর অনুমতি দেয় না, অন্যদিকে alwaysdata তাদের পেইড প্ল্যানে সুপারভাইজড কাস্টম সার্ভিস চালানোর সুবিধা দেয়।

একটি VPS-এ একই প্রোগ্রাম একটি systemd unit-এ পরিণত হয়:

sudo systemctl enable --now myapp
systemctl status myapp

systemctl status কমান্ডটি চালালে একটি প্রসেস আইডি (PID) সহ Active: active (running) আউটপুট আসার কথা। যদি এটি Active: failed (Result: exit-code) দেখায়, তবে এর কারণ journalctl -u myapp -n 50-এ পাওয়া যাবে, যা প্রোগ্রামটি বন্ধ হওয়ার মুহূর্তে তার নিজস্ব আউটপুট প্রদর্শন করে। ইউনিট ফাইলে Restart=always ব্যবহার করলে ক্র্যাশের পর প্রোগ্রামটি পুনরায় চালু হয় এবং enable ব্যবহার করলে রিবুটের পর এটি স্বয়ংক্রিয়ভাবে চালু হয়। systemd সার্ভিস এবং টাইমার লেখা হলো প্রথম VPS দক্ষতা যা সঠিকভাবে শেখা প্রয়োজন।

লক্ষণ 2: আপনার এমন একটি রানটাইম প্রয়োজন যা প্যানেলে নেই

প্যানেল আপনাকে একটি নির্দিষ্ট তালিকা প্রদান করে। যদি আপনার অ্যাপ্লিকেশনের জন্য সেই তালিকার বাইরের কোনো ল্যাঙ্গুয়েজ ভার্সন, কম্পাইল করতে হয় এমন কোনো লাইব্রেরি, ffmpeg, হেডলেস ব্রাউজার অথবা এমন কোনো ডাটাবেস প্রয়োজন হয় যা প্যানেল সমর্থন করে না (cPanel সাধারণত MySQL সমর্থন করে এবং হোস্টের সেটিংস অনুযায়ী PostgreSQL সমর্থন করতে পারে), তবে আপনার প্রোভাইডারের ইন্সটলেশন নিয়মগুলো যাচাই করুন। হোম ডিরেক্টরিতে সফটওয়্যার ইন্সটল করার জন্য সবসময় root অ্যাক্সেসের প্রয়োজন হয় না: DreamHost-এর ডকুমেন্টেশনে শেয়ার্ড সার্ভারে zlib এবং কাস্টম Python ভার্সন কম্পাইল করার নিয়ম দেওয়া আছে।

একটি VPS-এ আপনি apt install ব্যবহার করে এটি ইন্সটল করতে পারেন, অথবা আপনি এটিকে একটি কন্টেইনারে চালিয়ে হোস্ট সিস্টেমকে পরিষ্কার রাখতে পারেন। অ্যাপ্লিকেশনের একাধিক অংশ থাকলে VPS-এ Docker Compose ব্যবহার করাই সাধারণত প্রচলিত পদ্ধতি।

লক্ষণ 3: আপনার cron job সঠিক সময়ে চলতে হবে

শেয়ারড হোস্টিংয়ে একটি ফর্মের মাধ্যমে cron job জমা দিতে হয় এবং হোস্টিং প্রোভাইডার এর জন্য একটি সর্বনিম্ন বিরতি নির্ধারণ করে দিতে পারে। CloudLinux-এ, কোনো job যদি অ্যাকাউন্টের প্রসেসর লিমিট অতিক্রম করে, তবে সেটিকে বন্ধ না করে ধীরগতির করে দেওয়া হয়। ফলে একটি দীর্ঘমেয়াদী job পরবর্তী job শুরুর সময় পর্যন্ত চলতে পারে। যদি অ্যাকাউন্টটি ইতিমধ্যে তার প্রসেস ক্যাপাসিটিতে পৌঁছে যায়, তবে নতুন কোনো প্রসেস শুরু হতে পারে না। আপনি এর কিছু বিষয় পর্যবেক্ষণ করতে পারেন: cPanel-এর Cron Email সেটিং প্রতিটি job-এর আউটপুট আপনাকে ইমেইল করে। যেসব CloudLinux হোস্টে এই সুবিধা আছে, সেখানে প্যানেলের Resource Usage পেজে অ্যাকাউন্টের কোন লিমিট অতিক্রম হয়েছে এবং কতবার ত্রুটি হয়েছে তা দেখা যায়। সিস্টেম লগ দেখার সুযোগ এবং লিমিট বাড়ানোর ক্ষমতা হোস্টিং প্রোভাইডারের হাতেই থাকে, তবে কিছু প্রোভাইডার টাস্ক লগের শুরু এবং শেষের সময় দেখার সুযোগ দেয়।

একটি VPS-এ crontab -e ইনস্টল করা cron ইমপ্লিমেন্টেশন দ্বারা সমর্থিত শিডিউল গ্রহণ করে এবং systemd timer ব্যবহার করা আরও ভালো:

systemctl list-timers
journalctl -u cron -n 20

list-timers বর্তমানে মেমরিতে থাকা টাইমারগুলোর পরবর্তী এবং শেষ ট্রিগার হওয়ার সময় প্রদর্শন করে, তাদের সার্ভিসের এক্সিট রেজাল্ট নয়। cron জার্নালটি ইনস্টল করা cron সার্ভিস এবং লগিং কনফিগারেশনের ওপর নির্ভর করে। যখন কোনো job সম্পন্ন হয় না, তখন এর সার্ভিস স্ট্যাটাস এবং লগ পরীক্ষা করে দেখুন যে এটি আদৌ শুরু হয়েছিল কি না, নাকি শুরু হওয়ার পর ব্যর্থ হয়েছে। একটি শিডিউলড টাস্ক ডিবাগ করার মূল কাজই হলো এই পার্থক্যটি খুঁজে বের করা।

লক্ষণ 4: আপনার প্রতিবেশীরা আপনার রেসপন্স টাইম বাড়িয়ে দিচ্ছে

এই লক্ষণটি বেশ সুনির্দিষ্ট। আপনার কোডে কোনো পরিবর্তন না করা সত্ত্বেও, একই পেজ রাতে দ্রুত রেসপন্স করে কিন্তু সন্ধ্যা সাতটার দিকে ধীরগতির হয়ে যায়। কাউকে দোষারোপ করার আগে আপনার নিজের মেশিন থেকে এটি পরিমাপ করুন:

for i in $(seq 1 20); do curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/; sleep 5; done

time_starttransfer হলো রেসপন্সের প্রথম বাইট পাওয়ার সময়, যা সেকেন্ডে প্রকাশ করা হয়। যদি 20টি সংখ্যা কাছাকাছি থাকে, তবে তা ধারাবাহিক টাইমিং নির্দেশ করে, এটি সার্ভার, কোড বা ডাটাবেসের কোনো সমস্যা কি না তা নিশ্চিত করে না। যদি রাত 3টায় এই সময় স্থিতিশীল থাকে কিন্তু পিক আওয়ারে কয়েকশ মিলিসেকেন্ডের পার্থক্য দেখা দেয়, তবে প্রতিবেশীদের দোষারোপ করার আগে অ্যাকাউন্টের রিসোর্স ব্যবহার, রিকোয়েস্টের পরিমাণ এবং সার্ভার লগ তুলনা করে দেখুন। এই টাইমিংয়ের মধ্যে কানেকশন সেটআপ এবং সার্ভার প্রসেসিং অন্তর্ভুক্ত থাকে, তাই এগুলো নিজে থেকে সমস্যার মূল কারণ নির্ধারণ করতে পারে না।

এই পরিবর্তনের প্রকৃত খরচ

এই বিজ্ঞাপনগুলো 4 নভেম্বর, 2026 তারিখে যাচাই করা হয়েছে। এগুলো কোনো ক্যাটাগরি-ভিত্তিক গড় বা সবচেয়ে ছোট প্ল্যানের উদাহরণ নয়। শেয়ারড, 4 GB VPS এবং ম্যানেজড উদাহরণগুলো হলো যথাক্রমে DreamHost-এর Web Hosting Launch, Stack 4 এবং Managed VPS Business (বার্ষিক বিলিং অনুযায়ী); 1 GiB VPS হলো DigitalOcean-এর সাধারণ Basic Droplet (মাসিক ক্যাপ অনুযায়ী)। কেনার আগে বর্তমান মূল্য যাচাই করে নিন।

[
  {
    "plan": "Shared hosting, DreamHost",
    "first_term_usd": 2.89,
    "renewal_usd": 10.99
  },
  {
    "plan": "VPS, 1 vCPU 1 GiB, DigitalOcean",
    "first_term_usd": 6,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB, DreamHost",
    "first_term_usd": 6.99,
    "renewal_usd": 11.99
  },
  {
    "plan": "Managed VPS, 2 cores 2 GB, DreamHost",
    "first_term_usd": 13.75,
    "renewal_usd": 31.99
  }
]

মূল্য তালিকার এই পার্থক্য 2.89 থেকে 6 মার্কিন ডলার প্রতি মাসে, তবে শুধুমাত্র এই সংখ্যাটিই সবকিছু নির্ধারণ করে না। শেয়ারড হোস্টিংয়ের উদাহরণটিতে এক বছরের ফি অগ্রিম পরিশোধ করতে হয় এবং রিনিউয়াল ফি প্রতি মাসে 10.99 ডলার। রিনিউয়াল মূল্যের সাথে রিনিউয়াল মূল্যের তুলনা করলে চিত্রটি বদলে যায়: শেয়ারড অ্যাকাউন্টের জন্য 10.99 ডলারের বিপরীতে এন্ট্রি-লেভেল VPS-এর জন্য খরচ 6 ডলার। DigitalOcean-এর ক্ষেত্রে দুটি সংখ্যাই সমান, কারণ এই উদাহরণটিতে কোনো প্রারম্ভিক ছাড় নেই।

এই তুলনার ক্ষেত্রে সতর্ক থাকুন, কারণ সার্ভারের আকার সমান নয়। একটি 1 vCPU, 1 GB VPS একই ছোট বক্সে ওয়েব সার্ভার এবং ডাটাবেস চালায়, যা প্রকৃত ট্রাফিক আসা শুরু করলে WordPress-এর জন্য বেশ সংকীর্ণ হয়ে পড়ে। 2 vCPU, 4 GB-এর উদাহরণটি প্রতি মাসে 11.99 ডলারে রিনিউ হয়, কিন্তু শেয়ারড অ্যাকাউন্টের সীমাবদ্ধতা এবং VPS-এর সক্ষমতা সরাসরি বিনিময়যোগ্য নয়। এই উদাহরণগুলোতে শেয়ারড হোস্টিংয়ের তুলনায় এর রিনিউয়াল প্রিমিয়াম মাসে মাত্র এক ডলার।

প্রকৃত বড় খরচটি ইনভয়েসে দেখা যায় না। একটি VPS সেটআপ করতে এক ঘণ্টা সময় লাগে, প্রতি মাসে আপডেটের জন্য কয়েক মিনিট ব্যয় হয়, এবং প্রথমবার কোনো সমস্যা হলে সেটি ঠিক করতে আপনার একটি সন্ধ্যা নষ্ট হতে পারে। আপনার নিজের ঘণ্টার হারের সাথে এই সময়টির মূল্য যোগ করলে পার্থক্যের ব্যবধান দ্রুত কমে আসে। বাস্তবে একটি VPS-এর খরচ অংশে বিভিন্ন সাইজ নিয়ে বিস্তারিত আলোচনা করা হয়েছে।

ট্রাফিক না হারিয়ে শেয়ার্ড হোস্টিং থেকে সাইট স্থানান্তর

1. একদিন আগে, ডোমেইনের DNS (domain name system) TTL (time to live) কমিয়ে 300 সেকেন্ড করুন এবং পরিবর্তনের আগে আগের TTL শেষ হওয়ার জন্য অপেক্ষা করুন; লোকাল ক্যাশ আপডেট হতে এর চেয়ে বেশি সময় নিতে পারে।
2. নতুন সার্ভার তৈরি করুন এবং DNS পরিবর্তনের আগেই নতুন IP ঠিকানায় সাইটটি সচল করুন।
3. ফাইলগুলো কপি করুন, তারপর ডাটাবেস ডাম্প করে নতুন সার্ভারে রিস্টোর করুন।
4. আপনার ল্যাপটপের hosts ফাইল ব্যবহার করে পরীক্ষা করুন, যা শুধুমাত্র আপনার মেশিনের জন্য ডোমেইনটিকে নতুন IP-তে নির্দেশ করবে।
5. A record পরিবর্তনের আগে DNS validation ব্যবহার করে অথবা বিদ্যমান বৈধ সার্টিফিকেট দিয়ে নতুন সার্ভারে TLS (transport layer security) সার্টিফিকেট ইস্যু করুন এবং শেয়ার্ড হোস্টিং অ্যাকাউন্টটি আরও এক সপ্তাহ চালু রাখুন।

dig example.com A +noall +answer
rsync -avz ~/public_html/ deploy@203.0.113.10:/srv/www/example.com/
mysqldump --single-transaction -u dbuser -p dbname > site.sql

dig তার উত্তরের দ্বিতীয় কলামে TTL প্রদর্শন করে, তাই কোনো কিছু পরিবর্তন করার আগে আপনি নিশ্চিত হতে পারেন যে কম TTL কার্যকর হয়েছে কিনা। --single-transaction InnoDB টেবিলগুলোকে লক না করেই একটি সামঞ্জস্যপূর্ণ স্ন্যাপশট নেয়; নন-ট্রানজ্যাকশনাল টেবিল এবং একই সাথে চলমান স্কিমা পরিবর্তনের ক্ষেত্রে আলাদা সতর্কতা প্রয়োজন এবং পরবর্তী অর্ডারগুলো সেই স্ন্যাপশটে অন্তর্ভুক্ত থাকে না। নতুন সার্ভারে, একই দিনে সার্টিফিকেট সচল করুন: DNS রেকর্ড সার্ভারকে নির্দেশ করার পর Let's Encrypt on Ubuntu with nginx সেটআপ করতে মাত্র কয়েক মিনিট সময় লাগে।

দায়িত্বহীন রিসোর্স

যদি চারটি লক্ষণ আপনার সাইটের সাথে মিলে যায় কিন্তু রক্ষণাবেক্ষণের বিষয়টি আপনার কাছে আকর্ষণীয় মনে না হয়, তবে মাঝের বিকল্পটি হলো managed VPS। প্রোভাইডার চুক্তিবদ্ধ রক্ষণাবেক্ষণের দায়িত্ব পালন করে, তবে root access এবং ব্যবস্থাপনার পরিধি প্ল্যানের ওপর নির্ভর করে; DreamHost-এর managed VPS-এ root access অন্তর্ভুক্ত থাকে না। উপরের চার্টে এর 2 GB managed উদাহরণটিকে 31.99 ডলার এবং 4 GB unmanaged উদাহরণটিকে 11.99 ডলার হিসেবে দেখানো হয়েছে, তাই এটি সমান সাইজের কোনো তুলনা নয়। এই বাড়তি খরচের বিনিময়ে আপনি অন্য কারো সেবা পাচ্ছেন, যা সার্ভার রাতে সাড়া দেওয়া বন্ধ করে দিলে কাজে আসে।

যদি আপনার ক্ষেত্রে এটি প্রযোজ্য মনে হয়, তবে managed বনাম unmanaged VPS-এর সিদ্ধান্ত বিষয়টি পড়া আপনার জন্য পরবর্তী সঠিক পদক্ষেপ। আর যদি আপনি ইতিমধ্যে একটি ব্যস্ত VPS চালান এবং পিক আওয়ারে steal time-এর সমস্যা থেকে থাকে, তবে এর পরের ধাপ হলো কোনো প্রতিবেশী ছাড়া একটি dedicated server।

FAQ

shared hosting-এর তুলনায় VPS কি দ্রুত?

সব ক্ষেত্রে নয়। একটি শান্ত shared server একটি single WordPress পেজের ক্ষেত্রে 1 vCPU VPS-এর চেয়েও ভালো পারফর্ম করতে পারে। বরাদ্দকৃত মেমোরি CPU-এর চাপ পুরোপুরি দূর করতে পারে না: shared-CPU VPS-এর ক্ষেত্রে, পার্শ্ববর্তী ইনস্ট্যান্সগুলো রেসপন্স টাইমে প্রভাব ফেলতে পারে এবং মেমোরির নিশ্চয়তা প্রদানকারীর ওপর নির্ভর করে। যদি আপনার ওয়েবসাইট রাত 3টায় এবং সন্ধ্যা 7টায় সমানভাবে ধীরগতির হয়, তবে কোড, ডাটাবেস কুয়েরি এবং হোস্টিং রিসোর্সের সীমাবদ্ধতা পরীক্ষা করুন; দিনের সময় কোনো কারণ নির্ধারণ করে না।

আমি কি shared hosting-এ Node.js বা Python অ্যাপ চালাতে পারি?

প্রদানকারীর সীমাবদ্ধতার মধ্যে থেকে মাঝে মাঝে সম্ভব। কিছু কন্ট্রোল প্যানেল Passenger-এর মাধ্যমে আপনার জন্য অ্যাপ্লিকেশন চালু করে এবং অনুরোধ আসার সাথে সাথে তা চলতে শুরু করে। হোস্টের 80 এবং 443 পোর্টের মালিকানা অন্যান্য অনুমোদিত লিসেনারদের বাধা দেয় না: alwaysdata তাদের Public Cloud-এ IPv6-এর মাধ্যমে 8300 থেকে 8499 পোর্টে কাস্টম সার্ভিস চালানোর অনুমতি দেয়। পারসিস্টেন্ট প্রসেসের নিয়মগুলোও হোস্টভেদে ভিন্ন হয়, তাই একটি বট, কিউ ওয়ার্কার বা ওয়েব-সকেট সার্ভারের জন্য এমন একটি প্ল্যান প্রয়োজন যা স্পষ্টভাবে এটি সমর্থন করে, সব ক্ষেত্রে VPS-এর প্রয়োজন নেই।

VPS চালানোর জন্য কি আমার Linux জানা প্রয়োজন?

unmanaged VPS-এর ক্ষেত্রে, হ্যাঁ। আপনার SSH keys, firewall, আপডেট, ব্যাকআপ এবং লগ পড়ার অভ্যাস থাকা প্রয়োজন। প্রাথমিক সেটআপের জন্য এক ঘণ্টা এবং এরপর প্রতি মাসে কয়েক মিনিট সময় বরাদ্দ রাখুন। যদি আপনি এই কাজ করতে না চান, তবে একটি managed প্ল্যান রক্ষণাবেক্ষণের দায়িত্ব প্রদানকারীকে দিয়ে দেয়, যা managed বনাম unmanaged VPS hosting-এ আলোচনা করা হয়েছে।

shared hosting থেকে VPS-এ সরানোর সময় কি আমার সাইট ডাউন হয়ে যাবে?

DNS TTL কমিয়ে রাখা এবং উভয় অ্যাকাউন্ট চালু রাখা ডাউনটাইম এড়াতে সাহায্য করে, তবে এটি নিরবচ্ছিন্ন পরিবর্তনের নিশ্চয়তা দেয় না। পরিবর্তনের একদিন আগে TTL 300 সেকেন্ডে সেট করুন এবং আগের TTL শেষ হতে দিন, ফাইল ও ডাটাবেস কপি করুন, আপনার ল্যাপটপের hosts ফাইলের মাধ্যমে নতুন সার্ভার পরীক্ষা করুন, তারপর A record পরিবর্তন করুন। পরিবর্তনের সময় কিছু ভিজিটর পুরনো সার্ভারে এবং কিছু নতুন সার্ভারে পৌঁছাবে, এবং ক্যাশ আপডেট হতে পাঁচ মিনিটের বেশি সময় নিতে পারে, তাই shared অ্যাকাউন্টটি এক সপ্তাহ চালু রাখুন। চূড়ান্ত ডাটাবেস ডাম্প এবং রিস্টোরের সময় রাইট অপারেশন বন্ধ রাখুন এবং পুরনো সাইটটিকে read-only করে রাখুন অথবা এর অনুরোধগুলো নতুন সার্ভারে পাঠিয়ে দিন যাতে পরবর্তী রাইটগুলো হারিয়ে না যায়।