VPS Terurus vs Tidak Terurus: Mana Yang Anda Perlu?

VPS terurus berbanding tidak terurus: jawapan ringkas

Memilih antara VPS terurus (managed) atau tidak terurus (unmanaged) adalah persoalan tenaga kerja, bukan persoalan produk. Tidak terurus bermakna anda bertanggungjawab sepenuhnya terhadap patching, firewall, sandaran (backups), pemantauan, dan proses but semula pada pukul 2 pagi. Terurus bermakna penyedia perkhidmatan melakukan sebahagian daripada tugas tersebut untuk anda, dan skop tugas itu sangat berbeza antara hos. Satu-satunya perbandingan yang berguna ialah senarai tugas yang diambil alih oleh setiap pelan, dinilai berdasarkan kos masa anda sendiri.

Tiada definisi standard bagi perkataan terurus. Satu hos bermakna sistem pengendalian dikemas kini dan kakitangan menjawab tiket sokongan anda. Hos lain pula bermakna panel kawalan telah dipasang dan segala-galanya di atas lapisan tersebut adalah tanggungjawab anda. Hos ketiga pula bermakna kontrak perkhidmatan bertulis dengan masa respons yang ditetapkan. Dua pelan yang menggunakan perkataan yang sama boleh berbeza dalam setiap aspek yang penting, jadi baca dokumen skop sebelum anda melihat harga. Jika anda masih belum memutuskan tujuan mesin tersebut, apa yang sebenarnya boleh anda lakukan dengan VPS adalah soalan yang lebih baik untuk diselesaikan terlebih dahulu.

Tugas yang perlu dipertanggungjawabkan

Setiap pelayan yang berjalan mempunyai senarai tugas yang sama. Dalam pelan tanpa pengurusan, senarai itu adalah tanggungjawab anda. Dalam pelan terurus, anda membayar untuk mengurangkan beban tugas tersebut. Telusuri senarai ini dan tuliskan nama bagi setiap satu.

• Penampalan sistem pengendalian (patching), serta but semula yang diperlukan oleh kemas kini kernel.
• Peraturan firewall, yang perlu dikemas kini apabila anda menambah atau membuang servis. Asas firewall ufw untuk VPS merangkumi set peraturan permulaan.
• Akses SSH: pengendalian kunci, melumpuhkan log masuk kata laluan, membatalkan kunci apabila seseorang berhenti, dan cara untuk masuk semula apabila anda terkunci keluar.
• Sandaran (backups), salinan di luar tapak, dan pemulihan yang pernah anda lakukan sendiri.
• Pemantauan, yang bermaksud mengetahui bahawa pelayan boleh dicapai, cakera mempunyai ruang, servis masih berjalan, dan sijil belum tamat tempoh.
• Semakan log, dan tindakan susulan apabila terdapat sesuatu yang mencurigakan dalam log tersebut.
• Konfigurasi servis untuk pelayan web, pangkalan data, reverse proxy, dan baris gilir (queue) jika anda menggunakannya.
• Pembaharuan sijil, dan pembaikan apabila pembaharuan automatik gagal berfungsi.
• Kapasiti, yang bermaksud menyedari bahawa memori telah habis sebelum OOM (out of memory) killer bertindak bagi pihak anda.
• Tindak balas insiden, yang bermaksud perlu berjaga dan boleh dihubungi pada waktu yang tidak dijangka.

Kebanyakan tugas tersebut adalah rutin dan boleh diserahkan kepada skrip. Tindak balas insiden adalah satu-satunya tugas yang tidak boleh diautomasikan, kerana ia memerlukan seseorang yang boleh membuat keputusan. Itulah produk sebenar yang dijual oleh pelan terurus, sebab itulah senarai semak di bawah lebih banyak menumpukan soalan pada skop sokongan berbanding penampalan sistem.

Perkara yang biasanya tidak termasuk dalam pengurusan

Di sinilah pembeli sering terpedaya, jadi anda perlu jelas mengenainya. Kontrak terurus biasanya meliputi sistem pengendalian dan perisian yang dipasang oleh penyedia. Skopnya terhenti di sempadan aplikasi anda.

Kod anda adalah tanggungjawab anda. Ralat 500 daripada aplikasi anda bukanlah kerosakan pelayan. Penyedia akan mengesahkan bahawa proses pelayan web sedang berjalan dan memulangkan tiket tersebut kepada anda. Itu adalah sempadan yang adil. Ini juga merupakan jurang terbesar antara jangkaan pembeli dan apa yang sebenarnya mereka beli.

Masalah pada peringkat aplikasi biasanya di luar skop. Pertanyaan pangkalan data yang perlahan, pemalam yang rosak selepas kemas kini, cache yang tersalah konfigurasi, atau baris gilir mel yang berhenti diproses: semua ini berada di atas garisan sempadan walaupun penyedia memasang perisian di bawahnya.

Kebanyakan pemulihan data adalah di luar skop. Sandaran penyedia melindungi imej keseluruhan pelayan milik penyedia, dan ia wujud untuk kes kegagalan perkakasan hos. Ia jarang dibina untuk kes di mana anda memadamkan baris data, menjalankan migrasi yang salah, atau merosakkan fail enam minggu lalu dan baru menyedarinya hari ini. Tanya tentang tempoh pengekalan, sama ada fail tunggal boleh ditarik keluar, dan siapa yang menjalankan pemulihan.

Perisian yang anda pasang adalah tanggungjawab anda. Jika anda memasang Docker, penyedia biasanya memiliki hos manakala anda memiliki segala-galanya di dalam kontena tersebut.

Suntingan manual boleh membatalkan sokongan. Sesetengah kontrak menggugurkan komponen daripada skop sebaik sahaja pelanggan menyunting konfigurasinya secara terus. Tanya tentang perkara ini jika anda bercadang untuk melakukan sebarang penalaan.

Nilai masa anda berbanding delta bulanan

Ambil dua sebut harga di hadapan anda dan catatkan perbezaan bulanannya. Nombor tersebut ialah caj yang dikenakan oleh penyedia untuk membuang tugasan daripada senarai di atas. Sekarang, letakkan nilai pada bahagian anda dalam urus niaga ini.

• Berapakah nilai satu jam masa anda, dan berapa jam sebulan yang diperlukan oleh senarai tersebut setelah ia diautomasikan?
• Berapakah kos satu jam waktu henti (downtime) bagi perkara yang dijalankan pada pelayan ini?

Sebuah pelayan Ubuntu dalam keadaan stabil dengan kemas kini automatik dan pemantauan luaran memerlukan perhatian rutin yang sangat sedikit. Kebanyakan bulan, ia tidak memerlukan perhatian langsung. Kerja rutin adalah murah setelah skrip mengambil alih tugas tersebut. Gangguan (interrupts) adalah bahagian yang mahal, dan gangguan inilah yang dijual oleh pelan terurus. Jika pelayan menjalankan projek hobi, gangguan tidak menelan sebarang kos dan pilihan yang jelas ialah pelayan tidak terurus. Jika ia memproses pesanan, teliti sama ada kontrak sokongan benar-benar memendekkan tempoh gangguan, kerana penyedia terurus masih perlu membaca tiket anda, menghasilkan semula kerosakan, dan bertindak ke atasnya.

Delta tersebut juga berskala mengikut bilangan pelayan. Yuran terurus biasanya dikenakan bagi setiap pelayan, manakala automasi ditulis sekali dan disalin. Pelayan kedua mengurangkan separuh kos efektif skrip yang anda tulis untuk pelayan pertama, jadi baca cara mengurus berbilang pelayan Linux sebelum membuat komitmen terhadap yuran bagi setiap pelayan. Bagi angka asas pada kedua-dua belah perbandingan, kos sebenar VPS sebulan menetapkan harga lantai, dan pertukaran antara VPS dengan pelayan dedikasi menjadi penting apabila beban kerja cukup besar sehingga premium terurus hanyalah ralat pembundaran.

Soalan untuk diajukan kepada hos sebelum membayar premium terurus

Tanya sebelum anda membayar, dan minta jawapan secara bertulis. Halaman jualan bukanlah dokumen skop kerja.

1. Apakah skop kerja, tugasan demi tugasan? Minta senarai tersebut, bukan risalah pemasaran.
2. Adakah sokongan merangkumi perisian yang saya pasang, atau hanya perisian yang anda pasang?
3. Adakah anda melakukan patching secara automatik, dan adakah anda melakukan reboot untuk kemas kini kernel tanpa bertanya kepada saya terlebih dahulu?
4. Siapa yang bertanggungjawab jika patch yang anda gunakan merosakkan aplikasi saya?
5. Adakah anda membuat sandaran (backup)? Di manakah ia disimpan, berapa lama ia disimpan, dan siapa yang melakukan pemulihan (restore)?
6. Adakah anda pernah memulihkan pelayan pelanggan baru-baru ini, dan berapa lama masa yang diambil?
7. Berapakah masa tindak balas tiket, dan adakah ia berbeza pada jam 03:00 pagi hari Ahad?
8. Adakah saya mengekalkan akses root, dan adakah penggunaannya mengurangkan tahap sokongan yang anda berikan?
9. Adakah yuran dikenakan bagi setiap pelayan atau bagi setiap akaun?
10. Jika saya berhenti, apa yang boleh saya bawa bersama? Persediaan yang terikat di dalam panel kawalan proprietari boleh menjadi sukar untuk dieksport.

Soalan 5 menentukan kebanyakan soalan yang lain. Hos yang menjawabnya dengan tepat menunjukkan bahawa mereka pernah melakukannya sebelum ini. Jawapan yang samar-samar bermaksud proses pemulihan tidak pernah diuji, dan sandaran yang tidak diuji hanyalah satu salinan data. Soalan 5 juga mempunyai aspek lokasi: di mana salinan tersebut disimpan secara fizikal adalah isu perundangan dan juga teknikal, dan perkara yang benar-benar penting apabila anda memilih negara pengehosan membincangkan hal tersebut.

Jalan tengah: tanpa pengurusan serta automasi

Kebanyakan pembaca teknikal tidak mahukan mana-mana ekstrem. Mereka mahukan pelan tanpa pengurusan dengan kerja rutin diserahkan kepada mesin, manakala perhatian mereka tertumpu kepada perkara yang tidak dapat dinilai oleh mesin. Sediakan ia pada hari pertama. Sepuluh minit pertama pada VPS baharu ialah titik permulaan praktikal bagi sesiapa yang memilih pelan tanpa pengurusan, dan mengeraskan akses SSH perlu dilakukan dalam sesi yang sama.

Kemas kini keselamatan automatik

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

Fail tersebut kini sepatutnya mengandungi APT::Periodic::Update-Package-Lists "1"; dan APT::Periodic::Unattended-Upgrade "1";. Fail yang hilang, atau 0 pada mana-mana baris, bermakna tiada apa-apa yang berjalan dan anda tidak akan dimaklumkan.

Uji ia tanpa mengubah sistem. Perhatikan bahawa pakej tersebut ialah unattended-upgrades manakala perintahnya adalah dalam bentuk tunggal:

sudo unattended-upgrade --dry-run --debug

Output tersebut menyenaraikan setiap pakej yang dipertimbangkan dan berakhir dengan baris seperti No packages found that can be upgraded unattended apabila tiada apa-apa yang tertangguh. Pelaksanaan sebenar ditulis ke /var/log/unattended-upgrades/unattended-upgrades.log, jadi semak di sana daripada meneka.

Kemas kini kernel tidak mengubah apa-apa sehingga mesin but semula, kerana kernel yang sedang berjalan adalah yang dimuatkan semasa waktu but. Fail /var/run/reboot-required muncul apabila but semula tertangguh. Sama ada pantau fail tersebut, atau biarkan mesin mengendalikannya dalam /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot-WithUsers "false" menahan but semula sementara seseorang sedang log masuk, yang lebih selamat pada kotak yang anda gunakan secara interaktif dan tidak berguna pada kotak yang tiada sesiapa log masuk. Persediaan penuh unattended upgrades pada Ubuntu merangkumi sintaks senarai sekat dan pilihan e-mel.

Pemantauan yang berjalan di tempat lain

Pemantau yang berjalan pada pelayan tidak dapat memberitahu anda bahawa pelayan tersebut terhenti, kerana ia juga terhenti. Letakkan semakan pada hos kedua atau pada perkhidmatan luaran. Uptime Kuma untuk pemantauan status ialah jawapan biasa bagi perkhidmatan kendiri, dan ia perlu diletakkan pada mesin yang berbeza daripada mesin yang dipantaunya.

Pantau sekurang-kurangnya empat perkara: kebolehcapaian, penggunaan cakera, sama ada aplikasi menjawab pada port sebenar, dan tamat tempoh sijil. Cakera adalah perkara yang sering memerangkap pengguna. Fail log atau pangkalan data yang membesar sedikit setiap hari akan menjatuhkan sistem pada saat tiada apa-apa yang menjangkakannya, dan simptom pertama selalunya adalah perkhidmatan yang tidak dapat menulis dan terhenti.

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

Tambahkan juga denyutan nadi (heartbeat). Pemasa pada pelayan memanggil URL selepas setiap sandaran atau semakan kesihatan yang berjaya, dan pemantau akan memberi amaran apabila panggilan itu berhenti sampai. Pelayan yang senyap kemudiannya menghasilkan amaran sendiri, yang tidak dapat dilakukan oleh semakan tarik sahaja apabila laluan rangkaian adalah perkara yang terputus.

Sandaran yang telah anda pulihkan sekurang-kurangnya sekali

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init mencetak created restic repository <id> at sftp:... sekali. Menjalankannya terhadap repositori yang sudah wujud akan gagal dan bukannya menulis ganti, yang merupakan tingkah laku yang anda mahukan. Simpan salinan frasa laluan itu di luar pelayan: repositori tidak boleh dibaca tanpanya, dan tiada laluan pemulihan.

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots sepatutnya menyenaraikan pelaksanaan yang baru anda buat dengan tarikh hari ini. restic check mengesahkan struktur repositori dan mencetak no errors were found. Sekarang lakukan bahagian yang kebanyakan orang langkau:

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

Fail yang anda jangkakan sama ada ada di sana atau tidak, dan mengetahui sekarang hanya memakan masa sepuluh minit. Kemudian letakkan pelaksanaan tersebut pada pemasa supaya ia tidak bergantung kepada anda. Tulis /etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Dan /etc/systemd/system/restic-backup.timer:

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers menunjukkan pelaksanaan seterusnya dan masa yang tinggal. Hasil kosong bermakna anda mendayakan perkhidmatan dan bukannya pemasa, yang merupakan kesilapan paling biasa di sini. Persistent=true menjalankan tugasan yang terlepas selepas but seterusnya, jadi mesin yang dimatikan semalaman masih mendapat sandarannya. Sandaran Restic pada VPS mengupas lebih mendalam tentang susun atur repositori dan pengekalan, dan perkhidmatan dan pemasa systemd menjelaskan fail unit baris demi baris.

Apa yang tidak dibeli oleh automasi

Ia tidak membeli pertimbangan. But semula automatik pada 02:00 berlaku sama ada aplikasi anda kembali dengan lancar atau tidak, jadi sahkan setiap perkhidmatan bermula dengan sendirinya dan kemudian but semula dengan sengaja semasa anda berjaga:

systemctl is-enabled nginx docker
sudo reboot

Kemas kini tanpa pengawasan juga boleh memasang pakej yang merosakkan aplikasi anda, dan tiada apa-apa dalam saluran paip yang mengetahui perkara itu berlaku. Pemantau anda adalah perkara yang menangkapnya, itulah sebabnya pemantau tidak menjadi pilihan sebaik sahaja kemas kini menjadi automatik. Mesin menanggung rutin. Insiden itu masih milik anda.

Bilakah perkhidmatan terurus berbaloi dengan kosnya

Bersikap adil terhadap pihak perkhidmatan terurus. Empat situasi menjadikan pembelian ini pilihan yang tepat.

• Tiada sesiapa dalam pasukan yang mengendalikan Linux, dan tiada perancangan untuk mengambil pekerja baharu.
• Keperluan pematuhan menetapkan pihak yang bertanggungjawab untuk melakukan patching, dan pihak tersebut bukan anda.
• Stack tersebut merupakan kepakaran penyedia hos, jadi sokongan mereka pernah melihat kegagalan yang anda alami sebelum ini.
• Individu yang sepatutnya melakukan kerja tersebut ialah pekerja anda yang paling mahal, dan kos satu jam kerja mereka melebihi kos sebulan pelan premium.

Perkhidmatan terurus tidak semestinya lebih selamat secara automatik. Pelan terurus memang melakukan patching dengan lebih pantas berbanding pemilik yang kurang peka, dan itu merupakan kelebihan yang nyata. Mereka juga sering memasang control panel, iaitu aplikasi besar yang menghadap rangkaian dengan halaman log masuk dan sejarah kerentanannya sendiri. Itu boleh menjadi pertukaran yang munasabah, namun ia tetap satu pertukaran.

Keputusan tersebut sentiasa berbalik kepada senarai yang sama. Tuliskan sepuluh tugasan tersebut, tandakan siapa yang bertanggungjawab bagi setiap tugasan di bawah setiap sebut harga, kemudian bandingkan jurang tersebut dengan nilai satu jam perhatian anda. Kebanyakan pembaca teknikal yang melakukan perkara ini akhirnya memilih perkhidmatan tidak terurus dengan rutin yang diserahkan kepada penjadual (timer), dan itu merupakan jawapan yang boleh dipertahankan, bukannya sekadar pilihan murah.

FAQ

Apakah perbezaan antara VPS terurus (managed) dan tidak terurus (unmanaged)?

VPS tidak terurus memberikan anda mesin sahaja tanpa sebarang bantuan, jadi anda bertanggungjawab sepenuhnya ke atas patching, firewall, sandaran (backups), pemantauan, dan but semula selepas kemas kini kernel. VPS terurus memindahkan sebahagian daripada beban kerja tersebut kepada penyedia, biasanya pada lapisan sistem pengendalian dan perisian yang mereka pasang untuk anda. Sempadan sebenar ditentukan oleh setiap penyedia dan bukannya oleh istilah itu sendiri, jadi mintalah skop tugasan secara bertulis sebelum anda membandingkan harga.

Adakah VPS terurus bermakna saya tidak memerlukan sandaran sendiri?

Tidak. Sandaran penyedia biasanya melindungi imej keseluruhan pelayan milik penyedia dan wujud untuk kes kegagalan hos. Ia jarang membantu apabila anda memadam fail, menjalankan migrasi yang salah, atau merosakkan data beberapa minggu lalu dan baru menyedarinya hari ini. Tanya berapa lama snapshot disimpan, sama ada fail tunggal boleh dipulihkan, dan siapa yang melakukan pemulihan tersebut. Kemudian, simpan salinan luar tapak (offsite) anda sendiri dengan alat seperti restic, dan ujinya dengan restic restore latest --target /tmp/restore-check supaya anda tahu ia berfungsi.

Adakah VPS terurus lebih selamat daripada VPS tidak terurus?

Tidak semestinya. Pelan terurus melakukan patching lebih pantas berbanding pemilik yang tidak pernah log masuk, yang secara jujurnya mengurangkan risiko. Banyak pelan terurus juga memasang panel kawalan, dan panel adalah aplikasi besar yang menghadap rangkaian dengan halaman log masuk sendiri serta sejarah kerentanannya sendiri. Kotak tidak terurus dengan kemas kini keselamatan automatik, firewall yang tertutup, SSH berasaskan kunci sahaja, dan tiada perisian tambahan yang mendengar (listening) adalah sasaran yang lebih kecil berbanding kotak terurus yang menjalankan panel.

Bolehkah saya bermula dengan tidak terurus dan bertukar kepada terurus kemudian?

Biasanya boleh, walaupun ia jarang sekali semudah menanda kotak pilihan. Penyedia biasanya mengaudit atau membina semula pelayan sebelum mereka mengambil tanggungjawab ke atasnya, kerana mereka tidak akan menyokong konfigurasi yang tidak dapat mereka lihat. Tanya apa yang terlibat dalam proses onboarding, sama ada ia memerlukan pemasangan semula, dan sama ada apa-apa yang anda konfigurasi sendiri akan terkeluar daripada skop sokongan selepas itu.

Adakah saya mengekalkan akses root pada VPS terurus?

Pada kebanyakan pelan VPS terurus, anda memilikinya, tetapi akses root dan skop sokongan saling berkaitan. Sesetengah penyedia mengurangkan atau membatalkan sokongan untuk komponen yang anda edit secara manual, dan sesetengah akan membina semula daripada templat mereka sendiri jika tiket sokongan menjadi terlalu rumit. Dapatkan peraturan tersebut secara bertulis sebelum anda mengubah suai apa-apa, dan simpan fail konfigurasi anda dalam kawalan versi supaya pembinaan semula hanya memakan masa sejam dan bukannya sepanjang hujung minggu.