Yönetilen ve yönetilmeyen VPS arasındaki farklar nelerdir?

Yönetilen ve yönetilmeyen VPS: kısa cevap

Yönetilen ve yönetilmeyen bir VPS arasında seçim yapmak, bir ürün sorunu değil, bir iş gücü sorunudur. Yönetilmeyen VPS, yamaların, güvenlik duvarının, yedeklemelerin, izlemenin ve gece saat 02:00'deki yeniden başlatma işlemlerinin sorumluluğunun sizde olduğu anlamına gelir. Yönetilen VPS ise sağlayıcının bu sorumlulukların bir kısmını sizin yerinize üstlendiği anlamına gelir; ancak bu kısmın kapsamı barındırma sağlayıcıları arasında büyük ölçüde değişir. Yapılabilecek tek mantıklı karşılaştırma, her planın üzerinizden aldığı görevlerin listesini kendi çalışma saatlerinizin maliyetiyle kıyaslamaktır.

Yönetilen kelimesinin standart bir tanımı yoktur. Bir sağlayıcı için bu, işletim sisteminin yamalanması ve bir çalışanın destek taleplerine yanıt vermesi anlamına gelir. Bir diğeri için ise sadece bir kontrol panelinin kurulması ve panelin üzerindeki her şeyin sizin sorumluluğunuzda olması demektir. Üçüncü bir sağlayıcı için ise yanıt süresi taahhüdü içeren yazılı bir hizmet sözleşmesi anlamına gelebilir. Aynı kelimeyi taşıyan iki plan, önemli olan her konuda birbirinden farklı olabilir; bu nedenle fiyatı incelemeden önce hizmet kapsamı belgesini okuyun. Eğer makineyi ne amaçla kullanacağınıza henüz karar vermediyseniz, bir VPS ile gerçekte neler yapabileceğiniz sorusunu yanıtlamak ilk adım olmalıdır.

Birinin üstlenmesi gereken görevler

Çalışan her sunucu aynı görev listesini beraberinde getirir. Yönetilmeyen bir planda bu liste size aittir. Yönetilen bir planda ise bu listedeki maddelerin silinmesi için ödeme yaparsınız. Listeyi inceleyin ve her birinin yanına bir isim yazın.

• İşletim sistemi yamaları ve çekirdek güncellemelerinin gerektirdiği yeniden başlatma işlemleri.
• Servis ekleyip kaldırdıkça güncel tutulması gereken güvenlik duvarı kuralları. VPS için ufw güvenlik duvarı temelleri başlangıç kural setini kapsar.
• SSH erişimi: anahtar yönetimi, parola ile girişin devre dışı bırakılması, bir kişi ayrıldığında anahtarın iptal edilmesi ve kendinizi dışarıda bıraktığınızda sisteme geri giriş yöntemi.
• Yedeklemeler, tesis dışı bir kopya ve daha önce fiilen gerçekleştirdiğiniz bir geri yükleme işlemi.
• İzleme; yani sunucunun erişilebilir olduğunu, diskte yer bulunduğunu, servisin çalışmaya devam ettiğini ve sertifikanın süresinin dolmadığını bilmek.
• Günlük incelemesi ve bu günlüklerde hatalı bir durum görüldüğünde verilecek yanıt.
• Web sunucusu, veritabanı, reverse proxy ve eğer kullanıyorsanız kuyruk servisi için yapılandırma.
• Sertifika yenileme ve otomatik yenileme çalışmadığında yapılacak onarım.
• Kapasite yönetimi; yani out of memory (OOM) killer devreye girmeden önce bellek kullanımının dolduğunu fark etmek.
• Olay müdahalesi; yani seçmediğiniz bir saatte uyanık ve ulaşılabilir olmak.

Bunların çoğu rutin işlerdir ve bir betiğe devredilebilirler. Olay müdahalesi ise devredilemez, çünkü karar verebilecek bir insana ihtiyaç duyar. Yönetilen bir planın asıl sattığı ürün budur; bu yüzden aşağıdaki kontrol listesi, yama yönetimi yerine destek kapsamı ile ilgili sorulara daha fazla odaklanır.

Yönetilen hizmetlerin genellikle kapsamadığı alanlar

Alıcıların en çok mağdur olduğu nokta burasıdır, bu nedenle sınırları net bir şekilde belirlemek gerekir. Yönetilen bir sözleşme normal şartlarda işletim sistemini ve sağlayıcının kurduğu yazılımları kapsar. Sorumluluk, uygulamanızın sınırında sona erer.

Kendi kodunuz size aittir. Uygulamanızdan kaynaklanan bir 500 hatası, sunucu arızası değildir. Sağlayıcı, web sunucusu sürecinin çalıştığını teyit eder ve destek talebini size geri yönlendirir. Bu adil bir sınırdır. Aynı zamanda alıcıların beklentileri ile satın aldıkları hizmet arasındaki en büyük boşluktur.

Uygulama düzeyi sorunlar genellikle kapsam dışıdır. Yavaş bir veritabanı sorgusu, güncelleme sonrası bozulan bir eklenti, yanlış yapılandırılmış bir önbellek veya boşalmayı durduran bir posta kuyruğu; sağlayıcı alttaki yazılımı kurmuş olsa bile bu sorunlar kapsamın üzerindedir.

Veri kurtarma işlemlerinin çoğu kapsam dışıdır. Sağlayıcı yedekleri, sunucunun tamamına ait imajı korur ve bu yedekler donanım arızası durumları için oluşturulur. Altı hafta önce sildiğiniz bir satır, hatalı çalıştırdığınız bir migration veya bozulan bir dosya için genellikle tasarlanmamışlardır. Saklama süresinin ne kadar olduğunu, tek bir dosyanın geri getirilip getirilemeyeceğini ve geri yükleme işlemini kimin yaptığını mutlaka sorun.

Kurduğunuz yazılımlar size aittir. Docker kurduğunuzda, sağlayıcı genellikle ana makineden sorumluyken, container içindeki her şeyden siz sorumlu olursunuz.

Elle yapılan değişiklikler desteği geçersiz kılabilir. Bazı sözleşmeler, müşteri bir bileşenin yapılandırmasını doğrudan düzenlediğinde o bileşeni kapsam dışı bırakır. Herhangi bir ince ayar yapmayı planlıyorsanız bu durumu mutlaka sorgulayın.

Kendi zamanınızı aylık fark ile kıyaslayın

Önünüzdeki iki teklifi alın ve aralarındaki aylık farkı not edin. Bu rakam, sağlayıcının yukarıdaki listede yer alan iş yüklerini üzerinizden almak için talep ettiği bedeldir. Şimdi bu takasın kendi tarafınızdaki değerini belirleyin.

• Zamanınızın bir saati ne kadar değerli ve bu liste otomatize edildiğinde ayda kaç saatinizi alıyor?
• Bu sunucuda çalışan işin bir saatlik kesinti maliyeti nedir?

Otomatik güncellemeler ve harici izleme ile yapılandırılmış kararlı bir Ubuntu sunucusu, çok az rutin bakım gerektirir. Çoğu ay hiçbir müdahale gerekmez. Rutin işler, bir script tarafından yönetildiğinde maliyetsizdir. Asıl maliyetli olan kesintilerdir ve yönetilen hizmet planlarının sattığı şey de bu kesintilere müdahale etme garantisidir. Eğer sunucu bir hobi projesi barındırıyorsa, bir kesintinin maliyeti yoktur ve yönetilmeyen bir sunucu en mantıklı seçenektir. Eğer sunucu sipariş alıyorsa, bir destek sözleşmesinin kesinti süresini gerçekten kısaltıp kısaltmadığını dikkatle değerlendirin; çünkü yönetilen bir sağlayıcı da destek talebinizi okumak, hatayı yeniden üretmek ve müdahale etmek zorundadır.

Maliyet farkı, sunucu sayısı arttıkça da değişir. Yönetim ücretleri genellikle sunucu başına alınırken, otomasyon bir kez yazılır ve kopyalanır. İkinci sunucu, ilki için yazdığınız script'in etkin maliyetini yarıya indirir; bu nedenle sunucu başına ücret ödemeyi taahhüt etmeden önce birden fazla Linux sunucusu nasıl yönetilir konusunu okuyun. Karşılaştırmanın her iki tarafındaki temel rakamlar için bir VPS'in aylık gerçek maliyeti alt sınırı belirlerken, VPS ile dedicated sunucu arasındaki farklar konusu, iş yükü yönetilen hizmet bedelinin ihmal edilebilir bir hata payına dönüştüğü noktada önem kazanır.

Yönetilen hizmet bedeli ödenmeden önce barındırma sağlayıcısına sorulması gerekenler

Ödeme yapmadan önce sorun ve yanıtları yazılı olarak isteyin. Satış sayfası, bir kapsam dokümanı değildir.

1. Görev bazında nelerin kapsam dahilinde olduğu nedir? Broşür yerine liste isteyin.
2. Destek hizmeti sadece sizin kurduğunuz yazılımları mı, yoksa benim kurduğum yazılımları da kapsıyor mu?
3. Otomatik yama uyguluyor musunuz ve çekirdek güncellemeleri için bana sormadan yeniden başlatma yapıyor musunuz?
4. Uyguladığınız bir yama uygulamamı bozarsa sorumluluk kime aittir?
5. Yedek alıyor musunuz? Yedekler nerede saklanıyor, ne kadar süre tutuluyor ve geri yükleme işlemini kim gerçekleştiriyor?
6. Yakın zamanda bir müşteri sunucusunu geri yüklediniz mi ve bu işlem ne kadar sürdü?
7. Destek talebi yanıt süresi nedir ve pazar günü saat 03:00'te bu süre değişiyor mu?
8. root erişimim bende kalıyor mu ve bu erişimi kullanmam destek kapsamınızı daraltıyor mu?
9. Ücret sunucu başına mı yoksa hesap başına mı alınıyor?
10. Hizmeti sonlandırdığımda yanımda ne götürebilirim? Özel bir kontrol paneli içinde çalışan bir kurulumun dışa aktarılması zor olabilir.

1. soru, diğer soruların çoğunun yanıtını belirler. Bu soruya net bir yanıt veren sağlayıcı, bu işlemi daha önce yaptığını belirtmiş olur. Belirsiz bir yanıt, geri yükleme işleminin hiç test edilmediği anlamına gelir; test edilmemiş bir yedek sadece bir kopyadır. 5. sorunun bir de konum boyutu vardır: kopyaların fiziksel olarak nerede durduğu teknik olduğu kadar hukuki bir sorudur ve barındırma ülkesi seçerken gerçekten önemli olanlar konusu bunu detaylandırır.

Orta yol: yönetilmeyen sunucu ve otomasyon

Çoğu teknik okuyucu iki uç noktayı da tercih etmez. Rutin işlerin makine tarafından yapıldığı, kendi dikkatlerini ise makinenin karar veremeyeceği konulara ayırabilecekleri yönetilmeyen bir plan isterler. Bunu ilk günden kurun. Yeni bir VPS üzerinde ilk on dakika, yönetilmeyen sunucuyu seçen herkes için pratik bir başlangıç noktasıdır ve SSH erişimini sıkılaştırma da aynı ilk oturumun bir parçası olmalıdır.

Otomatik güvenlik güncellemeleri

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

Bu dosya artık APT::Periodic::Update-Package-Lists "1"; ve APT::Periodic::Unattended-Upgrade "1"; satırlarını içermelidir. Eksik bir dosya veya her iki satırda da bulunan bir 0, hiçbir şeyin çalışmadığı ve durumdan haberdar edilmeyeceğiniz anlamına gelir.

Sistemi değiştirmeden test edin. Paketin unattended-upgrades olduğunu, ancak komutun tekil olduğuna dikkat edin:

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

Çıktı, değerlendirilen her paketi listeler ve hiçbir güncelleme beklenmediğinde No packages found that can be upgraded unattended gibi bir satırla sona erer. Gerçek çalıştırmalar /var/log/unattended-upgrades/unattended-upgrades.log dosyasına yazılır, bu yüzden tahmin etmek yerine orayı kontrol edin.

Çalışan çekirdek önyükleme sırasında yüklendiği için, bir çekirdek güncellemesi makine yeniden başlatılana kadar hiçbir şeyi değiştirmez. Yeniden başlatma gerektiğinde /var/run/reboot-required dosyası görünür. Ya bu dosyayı izleyin ya da makinenin bunu /etc/apt/apt.conf.d/50unattended-upgrades içinde yönetmesine izin verin:

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

Automatic-Reboot-WithUsers "false", bir kullanıcı oturum açtığında yeniden başlatmayı bekletir; bu, etkileşimli olarak kullandığınız bir sunucuda daha güvenlidir, ancak kimsenin oturum açmadığı bir sunucuda işe yaramaz. Ubuntu üzerinde tam unattended-upgrades kurulumu, blok listesi sözdizimini ve e-posta seçeneklerini kapsar.

Başka bir yerde çalışan izleme

Sunucuda çalışan bir izleyici, sunucunun kapalı olduğunu size söyleyemez çünkü kendisi de kapalıdır. Kontrolü ikinci bir ana bilgisayara veya harici bir servise yerleştirin. Durum izleme için Uptime Kuma, genellikle tercih edilen self-hosted çözümdür ve izlediği makineden farklı bir makinede bulunmalıdır.

En az dört şeyi izleyin: erişilebilirlik, disk kullanımı, uygulamanın gerçek portunda yanıt verip vermediği ve sertifika geçerlilik süresi. İnsanları en çok yakalayan şey disk kullanımıdır. Her gün biraz büyüyen bir günlük dosyası veya veritabanı, başka hiçbir şeyin tahmin edemeyeceği bir anda sunucuyu durdurur ve ilk belirti genellikle yazamayan ve kapanan bir servistir.

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

Ayrıca bir kalp atışı (heartbeat) ekleyin. Sunucudaki bir zamanlayıcı, her başarılı yedekleme veya sağlık kontrolünden sonra bir URL'yi çağırır ve çağrı gelmeyi bıraktığında izleyici uyarı verir. Sessiz kalan bir sunucu kendi başına bir uyarı üretir; ağ yolu koptuğunda sadece çekme (pull-only) yöntemiyle çalışan bir kontrol bunu yapamaz.

En az bir kez geri yüklediğiniz yedekler

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, created restic repository <id> at sftp:... değerini bir kez yazdırır. Zaten var olan bir depoya karşı çalıştırmak, üzerine yazmak yerine hata verir; bu, istediğiniz davranıştır. Parolanın bir kopyasını sunucunun dışında bir yerde saklayın: depo onsuz okunamaz ve bir kurtarma yolu yoktur.

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, az önce yaptığınız ve bugünün tarihini taşıyan çalıştırmayı listelemelidir. restic check, depo yapısını doğrular ve no errors were found çıktısını verir. Şimdi çoğu insanın atladığı kısmı yapın:

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

Beklediğiniz dosya ya oradadır ya da değildir; bunu şimdi öğrenmenin maliyeti on dakikadır. Ardından, size bağımlı kalmaması için çalıştırmayı bir zamanlayıcıya bağlayın. /etc/systemd/system/restic-backup.service dosyasını yazın:

[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

Ve /etc/systemd/system/restic-backup.timer dosyasını:

[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, bir sonraki çalıştırmayı ve kalan süreyi gösterir. Boş bir sonuç, zamanlayıcı yerine servisi etkinleştirdiğiniz anlamına gelir; bu, burada yapılan en yaygın hatadır. Persistent=true, bir sonraki önyüklemeden sonra kaçırılan bir işi çalıştırır, böylece gece kapalı olan bir makine bile yedeklemesini alır. VPS üzerinde Restic yedeklemeleri, depo düzeni ve saklama politikaları hakkında daha fazla bilgi sunar; systemd servisleri ve zamanlayıcıları ise birim dosyalarını satır satır açıklar.

Otomasyonun size sağlamadıkları

Otomasyon size muhakeme yeteneği kazandırmaz. 02:00'deki otomatik bir yeniden başlatma, uygulamanızın düzgün bir şekilde ayağa kalkıp kalkmadığına bakılmaksızın gerçekleşir. Bu yüzden her servisin kendi kendine başladığını doğrulayın ve uyanıkken manuel olarak yeniden başlatın:

systemctl is-enabled nginx docker
sudo reboot

Otomatik bir güncelleme, uygulamanızı bozan bir paket de yükleyebilir ve süreçteki hiçbir şey bunun gerçekleştiğini bilmez. Bunu yakalayan şey izleyicinizdir; güncellemeler otomatik olduğunda izleyicinin isteğe bağlı olmamasının nedeni budur. Makine rutini kapsar. Olay yönetimi hala size aittir.

Yönetilen hizmetlerin maliyete değdiği durumlar

Yönetilen hizmetler tarafına karşı adil olunmalıdır. Dört durum, bu hizmetin doğru bir satın alma tercihi olmasını sağlar.

• Ekipte Linux yönetimi konusunda uzman kimse yoksa ve yeni bir işe alım planlanmıyorsa.
• Bir uyumluluk gereksinimi, yama yönetiminden sorumlu bir tarafı zorunlu kılıyorsa ve bu taraf siz olamıyorsanız.
• Kullanılan teknoloji yığını, servis sağlayıcının uzmanlık alanıysa; bu durumda destek ekibi yaşadığınız sorunu daha önce görmüş olabilir.
• Bu işi yapacak kişi ekibinizdeki en maliyetli çalışansa ve bu kişinin bir saatlik çalışma maliyeti, aylık hizmet bedelinden fazlaysa.

Yönetilen hizmetler otomatik olarak daha güvenli değildir. Yönetilen planlar, dikkatsiz bir sunucu sahibine kıyasla yamaları daha hızlı uygular ve bu gerçek bir kazanımdır. Bu hizmetler genellikle, kendine ait bir giriş sayfası ve güvenlik açığı geçmişi bulunan, ağa açık büyük bir uygulama olan bir kontrol paneliyle birlikte gelir. Bu makul bir takas olabilir, ancak yine de bir takastır.

Karar her seferinde aynı listeye dayanır. On görevi listeleyin, her bir teklif altında bu görevlerin sorumlusunun kim olduğunu işaretleyin ve ardından aradaki farkı, ayıracağınız bir saatlik dikkatin maliyetiyle karşılaştırın. Bunu yapan çoğu teknik okuyucu, rutin işleri bir zamanlayıcıya devrederek yönetilmeyen hizmetleri tercih eder; bu, ucuz bir çözüm olmaktan ziyade savunulabilir bir cevaptır.

FAQ

Yönetilen (managed) ve yönetilmeyen (unmanaged) VPS arasındaki fark nedir?

Yönetilmeyen bir VPS size yalnızca makineyi sağlar; bu nedenle yamalama, güvenlik duvarı, yedekleme, izleme ve çekirdek güncellemesi sonrası yeniden başlatma işlemleri sizin sorumluluğunuzdadır. Yönetilen bir VPS ise bu iş yükünün bir kısmını, genellikle işletim sistemi katmanını ve sizin için kurdukları yazılımları sağlayıcıya devreder. Kesin sınır, terimin genel tanımından ziyade her sağlayıcı tarafından belirlenir; bu nedenle iki fiyatı karşılaştırmadan önce görev bazlı kapsamı yazılı olarak talep edin.

Yönetilen bir VPS, kendi yedeklerime ihtiyaç duymadığım anlamına mı gelir?

Hayır. Sağlayıcı yedekleri genellikle sunucunun tamamına ait imajı korur ve ana makinenin arızalanması durumunda devreye girer. Bir dosyayı sildiğinizde, hatalı bir taşıma işlemi yaptığınızda veya haftalar önce veriyi bozup bugün fark ettiğinizde bu yedekler genellikle işe yaramaz. Snapshot'ların ne kadar süre saklandığını, tek bir dosyanın geri yüklenip yüklenemeyeceğini ve geri yükleme işlemini kimin gerçekleştirdiğini sorun. Ardından restic gibi bir araçla kendi yedeklerinizi sunucu dışı bir konumda tutun ve çalıştığından emin olmak için restic restore latest --target /tmp/restore-check ile test edin.

Yönetilen bir VPS, yönetilmeyene göre daha mı güvenlidir?

Kendi başına değil. Yönetilen bir plan, sisteme hiç giriş yapmayan bir kullanıcıdan daha hızlı yama yapar; bu da riski gerçekten azaltır. Birçok yönetilen plan ayrıca bir kontrol paneli kurar; panel ise kendi giriş sayfası ve güvenlik açığı geçmişi olan, ağa açık büyük bir uygulamadır. Otomatik güvenlik güncellemeleri, kapalı bir güvenlik duvarı, yalnızca anahtar tabanlı SSH erişimi olan ve fazladan hiçbir servisin dinlemede olmadığı yönetilmeyen bir sunucu, panel çalıştıran yönetilen bir sunucuya kıyasla daha küçük bir hedeftir.

Yönetilmeyen olarak başlayıp daha sonra yönetilene geçebilir miyim?

Genellikle evet, ancak bu nadiren bir onay kutusu kadar basittir. Sağlayıcılar, sorumluluğu üstlenmeden önce sunucuyu genellikle denetler veya yeniden kurarlar; çünkü görmedikleri bir yapılandırmaya destek veremezler. Onay sürecinin neleri kapsadığını, yeniden kurulum gerekip gerekmediğini ve kendi yapılandırdığınız nelerin kapsam dışında kalacağını sorun.

Yönetilen bir VPS'te root erişimim devam eder mi?

Çoğu yönetilen VPS planında root erişiminiz devam eder, ancak root erişimi ile destek kapsamı birbirini etkiler. Bazı sağlayıcılar elle düzenlediğiniz bir bileşen için desteği azaltır veya geçersiz kılar; bazıları ise destek talebi çok derinleşirse sunucuyu kendi şablonlarından yeniden kurar. Herhangi bir ayar yapmadan önce bu kuralı yazılı olarak alın ve yapılandırma dosyalarınızı sürüm kontrol sisteminde tutun; böylece bir yeniden kurulum bir hafta sonu yerine sadece bir saatinizi alır.