Storage VPS विरुद्ध नियमित VPS: कोणता निवडावा?

Storage VPS विरुद्ध नियमित VPS: थोडक्यात उत्तर

Storage VPS हा terabyte प्रमाणे विकला जाणारा virtual private server आहे, तर नियमित VPS हा core प्रमाणे विकला जातो. Storage plan मध्ये लहान CPU share मागे अनेक terabyte क्षमतेची मंद disk मिळते. Standard plan मध्ये वेगवान NVMe (non-volatile memory express) disk मिळते. तिची क्षमता अनेकदा वीस पट कमी असते. त्यासोबत त्याच किमतीत अधिक processor आणि अधिक memory मिळते. या दोन production मधील इतर सर्व बाबी समान असतात: तोच hypervisor, तोच root shell, तीच Ubuntu image आणि तोच network stack.

ही एकच बाब कोणता पर्याय योग्य आहे हे ठरवते. Backup targets, media libraries, cold archives आणि एकदा लिहून क्वचित वाचल्या जाणाऱ्या इतर डेटासाठी Storage VPS योग्य आहे. Database साठी किंवा वापरकर्ता प्रतीक्षा करत असलेल्या कोणत्याही page साठी तो योग्य नाही. अशा workload मध्ये छोटे random reads सुमारे एक millisecond मध्ये पूर्ण होणे आवश्यक असते. स्वस्त capacity स्वस्त असण्याचे नेमके कारण हेच आहे की ती अशी कामगिरी देऊ शकत नाही.

pricing page वर दिसणारी plan ची नावे

जवळपास प्रत्येक provider साठी चार labels पुरेसे असतात. त्यापैकी फक्त दोन labels चा विशिष्ट अर्थ असतो.

• Standard VPS. दोन ते आठ vCPU, 2 GB ते 32 GB RAM आणि host node वरच असलेले 20 GB ते 400 GB NVMe किंवा SATA SSD.
• Storage VPS. 1 TB ते 20 TB किंवा त्याहून अधिक storage. सहसा spinning SATA disks किंवा उच्च-क्षमता SATA SSDs असतात. यासोबत एक ते चार shared vCPU आणि मर्यादित RAM असते. याची मासिक किंमत अनेकदा छोट्या standard plan इतकीच असते.
• VDS. virtual dedicated server चे संक्षिप्त रूप. या संज्ञेची सर्वमान्य व्याख्या नाही. त्याऐवजी काय वाचावे, हे खालील section मध्ये दिले आहे.
• Block storage volume. हा plan मुळीच नाही. हा network-attached disk असतो, जो तुम्ही विद्यमान VPS मध्ये जोडता आणि ज्यासाठी दर महिन्याला प्रति GB पैसे देता. Server हलविल्याशिवाय वाढवता येणारा हा चारपैकी एकमेव पर्याय आहे.

या ranges संपूर्ण market मधील सामान्य स्वरूप दाखवतात. त्या कोणत्याही एका company च्या offer पुरत्या मर्यादित नाहीत. Plan वरील label ही एक category असते. त्यामुळे तुमचा server साधारणपणे कोणत्या chassis वर चालतो, याची कल्पना येते. मात्र disk type, CPU allocation policy किंवा bandwidth allowance यांची माहिती त्यातून मिळत नाही. तुमचा workload योग्यरीत्या चालेल की नाही, हे ठरवणाऱ्या मुख्य बाबी याच आहेत.

दोन योजनांमध्ये प्रत्यक्षात काय बदलते

डिस्कचा प्रकार आणि क्षमता. हाच दोन्ही उत्पादनांमधील मुख्य फरक आहे. Standard plan मध्ये PCI Express bus द्वारे जोडलेल्या NVMe flash वर तुम्हाला ठेवले जाते. Storage plan मध्ये मोठ्या spinning disks च्या array वर किंवा उच्च-क्षमता SATA SSDs वर जागा दिली जाते. यापैकी कोणता शब्द तुमच्यासाठी महत्त्वाचा आहे हे निश्चित नसल्यास, प्रथम SSD VPS म्हणजे काय आणि तो जुन्या disk plans पेक्षा कसा वेगळा आहे हे वाचा. त्यानंतर NVMe आणि SATA SSD मधील प्रत्यक्ष फरक पहा.

CPU चे प्रमाण. Storage plans मध्ये प्रत्येक terabyte मागे कमी vCPU असतात. हे vCPU जवळजवळ नेहमीच इतर tenants सोबत shared असतात. ही त्रुटी नाही. Backup target चे बहुतांश आयुष्य network ची वाट पाहण्यात जाते. त्यामुळे त्याला अधिक cores ची आवश्यकता नसते.

RAM. किमतीच्या तुलनेत Storage plans मध्ये RAM कमी असते. याचा परिणाम एका विशिष्ट ठिकाणी होतो: filesystem metadata. लाखो लहान files साठी directory आणि inode cache ठेवण्याकरिता memory आवश्यक असते. ती उपलब्ध नसल्यास प्रत्येक listing साठी पुन्हा disk वर जावे लागते.

Network allowance. Storage plan घेताना ही ओळ काळजीपूर्वक वाचा. ज्या capacity मधून restore करता येत नाही, ती backup नसते. मासिक transfer allowance TB मध्ये आणि port speed Gbit/s मध्ये तपासा. कारण 1 Gbit/s port वर 4 TB चा पूर्ण restore line rate ने सुमारे नऊ तास घेतो. Port shared असल्यास त्यापेक्षा बराच अधिक वेळ लागू शकतो.

[
  {
    "plan": "Storage VPS, HDD",
    "usd_per_tb_month": 3
  },
  {
    "plan": "Storage VPS, SATA SSD",
    "usd_per_tb_month": 9
  },
  {
    "plan": "Standard VPS, NVMe",
    "usd_per_tb_month": 40
  },
  {
    "plan": "Block storage add-on",
    "usd_per_tb_month": 90
  }
]

ही rounded figures आहेत. त्या August 2026 मध्ये अनेक providers च्या public price pages वरून घेतल्या आहेत. त्या कोणत्याही एका कंपनीचा quote नाहीत आणि त्यात बदल होऊ शकतो. मात्र एकूण रचना दीर्घकाळ तशीच राहते. Spinning storage plan मध्ये एका terabyte ची किंमत दरमहा सुमारे 3 US dollars असते. Standard plan मधील तेवढ्याच NVMe terabyte ची किंमत सुमारे 40 असते. Network attached block volume हा 4 पर्यायांपैकी सर्वाधिक महाग असतो आणि त्याची किंमत 90 असते. मासिक bill कशापासून बनते याचे विस्तृत चित्र पाहण्यासाठी VPS ची प्रत्यक्ष मासिक किंमत किती असते हे वाचा.

TB मागील किंमत आणि core मागील किंमत विरुद्ध दिशेने का बदलतात

Storage node म्हणजे बारा ते सोळा मोठ्या disks असलेले chassis आणि त्यांच्यासमोर एक मध्यम क्षमतेचा processor असतो. Compute node याच्या उलट असतो: अनेक cores, भरपूर RAM आणि दोन किंवा चार NVMe drives. Provider त्या chassis मध्ये शिल्लक असलेली संसाधने विकतो. त्यामुळे terabyte मागील किंमत कमी असलेल्या plan मध्ये core मागील किंमत जास्त असते, आणि core मागील किंमत कमी असलेल्या plan मध्ये terabyte मागील किंमत जास्त असते. दोन्ही बाबतीत स्वस्त plan नसतो, कारण कोणतेही chassis अशा प्रकारे तयार केलेले नसते.

म्हणून "मी कोणता plan घ्यावा?" या प्रश्नाचे प्रामाणिक उत्तर अनेकदा "दोन्ही" असे असते. Application चालवणारा छोटा NVMe VPS आणि त्याचे backups ठेवणारा storage VPS यांचा एकत्रित खर्च दोन्ही कामे योग्य प्रकारे करू शकेल अशा एका machine पेक्षा कमी असतो. एका machine ने खरोखरच दोन्ही कामे करणे आवश्यक असल्यास, तुम्ही VPS च्या मर्यादेबाहेर गेला आहात: dedicated server VPS पेक्षा कधी चांगला ठरतो.

स्वस्त disk random reads करू शकत नाही

[
  {
    "disk": "7200 rpm SATA HDD",
    "random_read_iops": "180",
    "typical_latency_ms": 8.5
  },
  {
    "disk": "SATA SSD",
    "random_read_iops": "75,000",
    "typical_latency_ms": 0.2
  },
  {
    "disk": "NVMe SSD",
    "random_read_iops": "600,000",
    "typical_latency_ms": 0.08
  }
]

ही आकडेवारी benchmark नसून datasheet मधील वर्गवारी दर्शवते; ती कोणत्याही provider ची चाचणी नाही. 7200 rpm disk दर सेकंदाला साधारण 180 random 4k reads हाताळतो. याचे कारण म्हणजे head ला track पर्यंत प्रत्यक्ष हलावे लागते आणि नंतर platter ने sector त्याच्या खाली आणेपर्यंत थांबावे लागते. या प्रक्रियेला प्रत्येक वेळी सुमारे 8.5 ms लागतात. Flash मध्ये हलवण्यासाठी कोणताही head नसतो. त्यामुळे SATA SSD सुमारे 75,000 आणि NVMe device 600,000 IOPS साध्य करते, तेही 0.08 ms मध्ये. हा फरक तीन हजार पटींपेक्षा जास्त आहे. RAM किंवा CPU वाढवूनही तो भरून निघत नाही.

Sequential कामाचे स्वरूप पूर्णपणे वेगळे आहे. म्हणूनच storage plans उपयुक्त ठरतात. एक spinning disk अजूनही 150 MB/s ते 250 MB/s वेगाने data stream करू शकतो. अनेक disks चा array यापेक्षा जास्त वेग देतो. त्यामुळे 1 Gbit/s port पूर्ण क्षमतेने वापरला जातो. Backup upload पूर्ण network speed ने चालतो आणि disk मर्यादा ठरत नाही. तुमची आकडेवारी array कसा तयार केला आहे यावरही अवलंबून असते. Striping केल्याने एक request अनेक disks मध्ये विभागली जाते: RAID 10 storage plan च्या performance मध्ये कसा बदल करतो यामध्ये त्याचे स्पष्टीकरण आहे.

VDS म्हणजे काय?

सामान्यतः हे marketing label असते. याचे तीन अर्थ प्रचलित आहेत आणि कोणता अर्थ लागू आहे हे provider क्वचितच स्पष्ट करतो. काही provider VDS हा pinned किंवा dedicated CPU cores साठी वापरतात. त्यामुळे तुमच्या CPU cycles साठी इतर tenant स्पर्धा करत नाहीत. काही provider VDS हा KVM सारख्या full virtualization साठी वापरतात. हे LXC किंवा OpenVZ सारख्या container virtualization पेक्षा वेगळे आहे, कारण त्यामध्ये host kernel सामायिक केला जातो. काही provider VDS हा VPS पेक्षा अधिक सक्षम वाटणाऱ्या नावाव्यतिरिक्त इतर कोणत्याही अर्थाने वापरत नाहीत.

यातील काही बाबी server मधूनच पडताळता येतात. systemd-detect-virt full virtual machine वर kvm आणि container वर lxc छापते. Container असल्यास kernel modules load करता येत नाहीत आणि स्वतःचा kernel चालवता येत नाही. Dedicated CPU च्या दाव्याची पडताळणी करण्यासाठी खाली दिलेली steal time तपासणी वापरावी लागते. Plan वरील अक्षरांकडे संकेत म्हणून पाहा आणि specification मधील ओळींना करारातील अटी माना.

नावाऐवजी तपासायच्या specification ओळी

• क्षमतेजवळ छापलेला शब्द: NVMe, SSD, SATA किंवा HDD. पृष्ठावर कुठेही disk असा शब्द दिसत नसेल, तर त्या किमतीत बसणारे सर्वात स्वस्त hardware गृहीत धरा.
• disk node वर local आहे की network attached आहे, हे तपासा. Network attached storage प्रत्येक request वर latency वाढवते आणि node failure नंतरही उपलब्ध राहते. Local disk वेगवान असतो; मात्र node बंद पडल्यास तोही उपलब्ध राहत नाही.
• CPU चे वर्णन तपासा: "dedicated" किंवा "pinned" यांच्याविरुद्ध "shared", "fair share" किंवा कोणतेही वर्णन नाही.
• plan मध्ये दिलेली IOPS किंवा MB/s मर्यादा तपासा. 500 IOPS ची मर्यादा असल्यास disk type जवळजवळ अप्रासंगिक ठरतो.
• Monthly transfer allowance आणि port speed तपासा. यावर full restore पूर्ण होण्यासाठी लागणारा वेळ ठरतो.
• snapshots, backups आणि अतिरिक्त IP addresses समाविष्ट आहेत की त्यांचे स्वतंत्र billing केले जाते, हे तपासा.

तुम्हाला प्रत्यक्षात मिळालेली डिस्क कशी तपासावी

सुरुवातीला kernel काय अहवाल देतो ते पाहा. त्यानंतर त्यावर विश्वास ठेवणे थांबवा.

lsblk -d -o NAME,ROTA,SIZE,MODEL
df -h /
nproc
free -h

ROTA हे rotational device साठी 1 आणि flash साठी 0 असते. VPS मध्ये त्यावर अवलंबून राहू नका. virtio disk सहसा ROTA=0 अहवाल देते, कारण hypervisor एक generic block device सादर करतो आणि guest ला physical drive दिसत नाही. त्याच कारणामुळे MODEL रिकामे असते. हा flag hypervisor ने काय घोषित केले ते दर्शवतो; rack मध्ये प्रत्यक्षात काय फिरत आहे ते नाही. त्यामुळे प्रत्यक्ष मोजमाप करा.

sudo apt update && sudo apt install -y fio
fio --name=randread --filename=/var/tmp/fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fio.test

--direct=1 page cache वगळते. त्यामुळे RAM ऐवजी डिस्कचे मोजमाप होते. वाचायची ओळ read: IOPS= आहे. तिच्या खाली clat percentiles (usec) मधील distribution दिसते. Standard NVMe plan मध्ये 99th percentile one millisecond पेक्षा कमी असताना IOPS ची संख्या साधारणपणे tens of thousands असते. Spinning storage plan मध्ये IOPS साधारणपणे काही hundred असतात आणि 99th percentile double-digit milliseconds मध्ये असते. fio ने libaio engine load करता येत नसल्याचे दाखवले, तर --ioengine=psync --iodepth=1 वापरा. त्या वेळी कमी numbers अपेक्षित ठेवा, कारण ते engine एका वेळी एकच request पाठवते.

vmstat 1 5
sudo apt install -y sysstat
iostat -x 1 5

vmstat मध्ये st column हा steal time आहे. host ने ते CPU cycles दुसऱ्या guest ला दिले असताना तुमचा vCPU run होण्यासाठी तयार असलेल्या वेळेचा हा वाटा असतो. ही संख्या सातत्याने 5 पेक्षा जास्त असल्यास node oversubscribed आहे. "dedicated CPU" या दाव्याची हीच खरी चाचणी आहे. iostat -x मध्ये %util, r_await आणि w_await वर लक्ष ठेवा. %util जवळपास 100 असून w_await tens of milliseconds मध्ये असल्यास disk हा bottleneck आहे. कोणतेही application tuning यावर उपाय करू शकणार नाही. Flash साठीच्या विशिष्ट तपासण्यांसाठी NVMe disk खरोखर NVMe आहे का ते पडताळणे अधिक सखोल माहिती देते.

कामाच्या प्रकारानुसार निवड

• restic, Borg किंवा rsync साठी backup target. Storage VPS यासाठी योग्य आहे; त्याची निर्मितीच या कामासाठी केली आहे. Writes मोठ्या आणि सलग असतात. Deduplication source machine वर होते. निकालाची प्रतीक्षा करणारी कोणतीही प्रक्रिया नसते. एक महत्त्वाची बाब: restic prune आणि restic check --read-data संपूर्ण repository लहान भागांमध्ये read करतात. त्यामुळे त्यांच्यासाठी काही तास राखून ठेवा आणि ते schedule नुसार चालवा. VPS वर restic backups चालवणे पहा.
• Immich किंवा Jellyfin media library. Files साठी Storage VPS वापरा; मात्र CPU बाबत सावध रहा. Import वेळी Immich thumbnails तयार करते आणि machine learning jobs चालवते. Playback वेळी Jellyfin transcoding करते. दोन shared vCPU असतील, तर 200 GB फोटोंचा पहिला import अत्यंत संथ होईल. Database आणि thumbnail cache सर्वात वेगवान disk वर ठेवा. Google Photos च्या पर्यायाप्रमाणे Immich self-host करणे यामध्ये sizing ची माहिती आहे.
• PostgreSQL किंवा MySQL. Standard NVMe plan निवडा. प्रत्येक commit चा शेवट fsync मध्ये होतो. Transaction return होण्यापूर्वी ते durable storage पर्यंत पोहोचणे आवश्यक असते. त्यामुळे commit latency ही disk latency असते. Index lookup म्हणजे 8 kB चा random read असतो, आणि spinning disk साठी हीच सर्वात प्रतिकूल कामगिरीची पद्धत आहे.
• Web application, API किंवा control plane. Standard plan निवडा. यांना CPU cores आणि अंदाज करता येईल अशी latency आवश्यक असते. त्यांना क्वचितच 100 GB पेक्षा जास्त storage लागते.
• CI cache किंवा artifact store. हे file size वर अवलंबून असते. मोठे tarballs storage plan मधून पूर्ण network speed ने stream होतात. शेकडो हजारो लहान files चा cache अनेक runners कडून parallel पद्धतीने pull केला जात असेल, तर ते प्रत्यक्षात random IO असते आणि त्याची कामगिरी निराशाजनक ठरते.

तुमची रचना चुकीची असल्यास ती कशी दिसते

अपयश त्वरित दिसून येत नाही. Spinning storage plan वर चालणारा database एका वापरकर्त्यासह सुरळीत वाटतो, पण दहा वापरकर्त्यांखाली तो ठप्प होतो. याचे कारण म्हणजे पूर्वी RAM मधून पूर्ण होणाऱ्या queries आता disk वर जातात आणि प्रत्येक query ला microseconds ऐवजी milliseconds लागतात. Load average वाढतो, तर top मध्ये CPU बहुतांश वेळ idle असून %wa चे मूल्य जास्त दिसते. याचा अर्थ processes computation करण्याऐवजी disk ची वाट पाहत blocked आहेत. iostat -x 1 मध्ये %util जवळपास 100 वर स्थिर दिसतो.

PostgreSQL च्या स्वतःच्या log मध्ये हे स्पष्टपणे दिसते, कारण version 15 पासून log_checkpoints default ने enabled आहे:

LOG:  checkpoint complete: wrote 8241 buffers (2.5%); ... write=112.402 s, sync=9.318 s, total=121.914 s

sync= चे मूल्य महत्त्वाचे आहे. Checkpoint ने fsync कडून प्रतिसाद मिळण्याची वाट पाहण्यात घालवलेला हा वेळ आहे. त्यामुळे हे मूल्य seconds मध्ये असल्यास database ज्या वेगाने writes निर्माण करतो, त्या वेगाने disk त्या writes स्वीकारू शकत नाही. Query स्वतः स्वस्त असली तरी त्या कालावधीत client connections अडकतात. यावर configuration change हा उपाय नाही. Data directory NVMe वर हलवा आणि backups साठवण्यासाठी हा storage plan वापरा; त्यासाठीच तो योग्य आहे.

FAQ

स्टोरेज VPS नेहमीच्या VPS पेक्षा धीमा असतो का?

Random read आणि write साठी होय, आणि फरक मोठा असतो. Spinning storage plan वर प्रति सेकंद काहीशे लहान random requests मिळतात आणि प्रत्येकास सुमारे 8 ms लागतात. NVMe plan वर प्रति सेकंद हजारो requests मिळतात आणि प्रत्येकास 1 ms पेक्षा कमी वेळ लागतो. Sequential transfer साठी दोन्हीमधील फरक कमी असतो, कारण storage array अजूनही 150 MB/s किंवा त्याहून अधिक वेगाने data stream करू शकतो. 1 Gbit/s port पूर्ण क्षमतेने वापरण्यासाठी हा वेग पुरेसा आहे. निर्णय घेण्यापूर्वी fio --rw=randread --bs=4k --direct=1 वापरून तुमच्या सिस्टीमचा वेग मोजा.

मी storage VPS वर PostgreSQL चालवू शकतो का?

तुम्ही ते सुरू करू शकता आणि working set RAM मध्ये बसेपर्यंत ते कार्यरत राहील. त्यानंतर प्रत्येक commit साठी धीम्या disk वर fsync पूर्ण होण्याची प्रतीक्षा करावी लागते. Postgres हे checkpoint complete मध्ये सेकंदांमध्ये sync= म्हणून नोंदवते. त्याच वेळी iostat -x 1 मध्ये %util जवळपास 100 आणि w_await जास्त असल्याचे दिसते. सर्वसाधारण रचना अशी असते: database साठी छोटा NVMe VPS आणि त्याच्या dump साठी destination म्हणून storage VPS.

VDS म्हणजे मला dedicated hardware मिळते का?

विश्वसनीयपणे असे म्हणता येत नाही. VDS या संज्ञेचा कोणताही standard अर्थ नाही. काही providers ती pinned CPU cores साठी वापरतात. काही providers shared-kernel container ऐवजी full KVM virtualization साठी ती वापरतात. काही providers ती केवळ नाव म्हणून वापरतात. तुम्ही systemd-detect-virt चालवून तुम्ही kvm वर आहात की lxc वर, हे पाहू शकता. तसेच vmstat 1 5 चालवून st column वर लक्ष ठेवा. यामुळे इतर tenants तुमचे CPU cycles वापरत आहेत का ते समजेल.

माझ्या VPS ची disk खरोखर NVMe आहे की नाही हे कसे तपासू?

lsblk -d -o NAME,ROTA,MODEL वर विश्वास ठेवू नका, कारण virtio disk खाली कोणते hardware आहे याची पर्वा न करता सामान्यतः ROTA=0 आणि रिकामी model string दाखवते. --direct=1 सह 30 सेकंदांची fio random read test चालवा. त्यानंतर IOPS आणि 99th percentile latency तपासा. दोन अंकी milliseconds मध्ये शेकडो IOPS मिळत असतील, तर ती spinning array आहे. 1 millisecond पेक्षा कमी latency मध्ये दहा हजारो IOPS मिळत असतील, तर ती flash storage आहे.