Önce iş yükünü tanımlayın
Web sitesi, ERP, veritabanı, dosya paylaşımı ve geliştirme ortamı farklı kaynaklara ihtiyaç duyar. Teklif talebinde çalışacak uygulamalar, eşzamanlı kullanıcı sayısı, mevcut veri boyutu ve yoğun saatler paylaşılmalıdır. Uygulama üreticisinin önerdiği işletim sistemi ve veritabanı sürümleri başlangıç noktasıdır.
Mevcut bir sunucudan geçiş yapılıyorsa CPU ve RAM kullanımı ile disk okuma/yazma değerlerini gözlemlemek kapasiteyi daha doğru belirlemeye yardımcı olur. Ortalama kullanımın yanında ay sonu raporları, toplu işlemler veya kampanya dönemleri gibi tepe yükler de hesaba katılmalıdır.
VDS hangi ihtiyaçlara uygundur?
VDS, fiziksel altyapı üzerinde ayrı işletim sistemi ortamı sunan sanal sunucudur. Web uygulamaları, geliştirme ortamları ve uygun gereksinimlere sahip kurumsal yazılımlar için değerlendirilebilir. Kaynak büyütme seçenekleri altyapının imkanlarına bağlıdır; teklif sırasında sınırlarını sorun.
vCPU sayısı tek başına performansı açıklamaz. İşlemci paylaşım modeli, depolama gecikmesi, ağ kapasitesi ve sanallaştırma koşulları da önemlidir. Windows veya ticari veritabanı lisanslarının bedeli ve kullanım şartları ayrıca değerlendirilmelidir.
Fiziksel sunucu ne zaman değerlendirilir?
Sürekli yüksek kaynak tüketimi, özel donanım ihtiyacı, yoğun veritabanı işlemleri veya çok sayıda sanal makine için fiziksel sunucu uygun olabilir. Donanım tek müşterinin kullanımına ayrılır; kapasite artışında donanım değişikliği veya yeni sunucu planı gerekebilir.
Dedicated kiralamada donanım sağlayıcıya aittir. Kurumun kendi donanımını veri merkezine yerleştirmesi ise colocation hizmetidir. Bu iki modelde donanım yatırımı, bakım ve arıza sorumlulukları farklıdır.
Yönetim ve toplam maliyeti karşılaştırın
İşletim sistemi güncellemeleri, uygulama yönetimi, güvenlik duvarı, izleme ve yedekleme görevleri otomatik olarak her kiralama hizmetine dahil değildir. Yönetilen hizmet talep ediyorsanız görevleri ve müdahale kapsamını yazılı olarak belirleyin.
Toplam maliyeti hesaplarken sunucu bedeline lisanslar, yedek depolama, ağ kullanımı ve operasyon ihtiyacını ekleyin. Taşıma öncesinde test ortamı oluşturulması, geri dönüş adımlarının belirlenmesi ve DNS geçişinin planlanması riski azaltır.
Örnek senaryo: ofisteki iş uygulamasını veri merkezine taşımak
Örnek olarak, ofisindeki sunucudan muhasebe uygulamasına erişen bir şirketi düşünelim. Ekip yeni bir sunucu almak yerine kiralama seçeneğini araştırıyor. Buradaki ilk soru “kaç çekirdek kiralamalıyız?” değildir. Kullanıcıların uygulamaya nasıl bağlanacağı, dosyaların nerede tutulacağı ve ofis bağlantısı kesilirse hangi işlerin duracağı anlaşılmalıdır. Sunucu veri merkezine taşındığında, daha önce yerel ağda gerçekleşen erişim internet bağlantısına bağımlı hale gelebilir.
Böyle bir geçişte VDS teknik olarak yeterli olabilir; ancak yazılım üreticisinin destek koşulları, lisanslar ve erişim yöntemi kontrol edilmeden karar verilmez. Önce ayrı bir ortamda uygulama açılır, kullanıcı işlemleri denenir ve rapor süresi gözlenir. Canlı verinin son aktarımı için bir zaman belirlenir. Eski sunucunun ne zaman kapatılacağı da test sonucuna bağlanır.
Teklifte aynı isimle geçen kaynaklar her zaman aynı değildir
İki teklifte de “8 vCPU” yazması, işlemci tarafında eşit kapasite sunulduğu anlamına gelmez. İşlemci nesli, paylaşım oranı ve sanallaştırma koşulları sonuçları etkiler. Benzer şekilde “NVMe disk” ifadesi depolama teknolojisini anlatır; uygulamanızın erişebileceği IOPS, aktarım hızı veya gecikme hakkında tek başına kesin bir değer vermez. Ölçülebilir ihtiyacınız varsa bu değerleri ve uygulanacak sınırları sorun.
Ağ tarafında port hızı, dahil trafik ve kullanılabilir bant genişliği ayrı ayrı açıklanmalıdır. Teklifte yer alan kapasitenin sürekli kullanım mı, belirli sınırlar içindeki kullanım mı olduğu görülmelidir. Aynı tabloya lisans ve destek kalemlerini de ekleyin. Bir teklifte işletim sistemi lisansı veya yedek alanı bulunurken diğerinde bulunmaması, ilk bakışta daha ucuz görünen seçeneğin toplam maliyetini değiştirebilir.
Performans sıkıntısının nerede başladığını ayırın
Uygulama yavaşladığında sunucu kaynaklarını artırmak bazen çözüm olur, bazen de aynı sorunu daha büyük bir makineye taşır. CPU doygunluğu, bellek baskısı ve disk bekleme süreleri gözlenebilir; fakat ağ gecikmesi, veritabanı sorgusu veya uygulamadaki bir kilit de benzer şikayetler yaratır. “Rapor geç açılıyor” gibi bir bildirim, hangi saatte ve hangi işlemde yaşandığıyla birlikte kaydedildiğinde daha anlamlıdır.
Yazılım ve altyapı ekiplerinin aynı zaman aralığındaki ölçümleri karşılaştırması gerekir. Sorun yalnızca belirli bir raporda ortaya çıkıyorsa uygulama sorgusunu incelemek; bütün işlemlerde ve bütün kullanıcılarda yaşanıyorsa ortak kaynakları kontrol etmek daha iyi bir başlangıçtır. Teklif değerlendirmesinde, mevcut sorunu tanımlayan bu bilgiler donanım listesinden daha değerli olabilir. Kapasite artışını ölçümden sonra yapmak gereksiz harcamayı azaltır.
Yönetilen hizmetin sınırını görevlerle tarif edin
“Yönetim dahil” ifadesini tek başına bırakmayın. İşletim sistemi güncellemesini, erişim yetkilerini, yedek işlerini ve alarm takibini kimin yapacağını yazın. Veritabanının kurulması ile veritabanı performansının sürekli izlenmesi farklı iştir. Uygulamanın açılmasıyla uygulama içindeki işlevlerin desteklenmesi de aynı hizmet değildir. Hangi sorun için hangi ekibe başvuracağınız belli olmalıdır.
Kurumda teknik personel bulunuyorsa bazı görevler içeride yürütülebilir. Teknik ekibi olmayan bir işletmenin ihtiyacı ise yalnızca sunucu erişim bilgilerini almakla karşılanmayabilir. Destek saatleri, müdahale yöntemi ve değişikliklerin onay süreci konuşulmalıdır. Bu görev tablosu, VDS ile fiziksel sunucu arasında yaptığınız seçimin sonrasında nasıl işletileceğini de gösterir. Donanım seçimi ile operasyon modelini aynı görüşmede ele almak yararlıdır.
Taşımayı tamamlamak için son kontrol
Canlıya geçişten sonra oturum açma ve web sitesinin açılması ilk kontroldür; tek başına yeterli değildir. Zamanlanmış işler, e-posta bildirimleri, dosya yolları ve dış sistem bağlantıları da denenmelidir. Eski sunucuda çalışan, adı pek bilinmeyen bir görev yeni ortamda eksik kalabilir. Uygulamanın günlük iş akışı sırasında yaptığı işlemler kısa bir kontrol listesine çevrilebilir.
Yeni sistemde yedek işinin çalıştığı ve geri yükleme yolunun bilindiği doğrulandıktan sonra eski ortamın kapanışı planlanır. Eski erişimlerin kaldırılması, gereksiz yönetici hesaplarının kapatılması ve gerekli belgelerin güncellenmesi geçişin parçasıdır. Disket’e teklif talebi iletirken mevcut sunucunun ölçümlerini, uygulama gereksinimlerini ve bu geçiş beklentilerini paylaşmanız, seçeneklerin aynı kapsamda karşılaştırılmasına yardımcı olur.
İki sunucu teklifini aynı kapsamda karşılaştırın
| Sorulacak konu | VDS için kontrol | Fiziksel sunucu için kontrol |
|---|---|---|
| İşlemci | vCPU sayısı ve paylaşım koşulları | İşlemci modeli, çekirdekler ve kullanım ayrımı |
| Depolama | Kota, IOPS veya aktarım sınırları | Disk modeli, kapasite ve yedeklilik |
| Büyüme | Kaynak artışının yöntemi ve sınırları | Yeni donanım veya ikinci sunucu ihtiyacı |
| Lisanslar | İşletim sistemi ve uygulama kullanım koşulları | İşletim sistemi ve uygulama kullanım koşulları |
| Operasyon | Güncelleme, alarm ve yedek görevleri | Güncelleme, alarm, yedek ve donanım müdahalesi |
Teklif öncesi kontrol listesi
- Uygulamalar, sürümler ve üretici gereksinimleri
- Eşzamanlı kullanıcı, tepe yük ve veri büyümesi
- Kaynak paylaşımı, disk ve ağ sınırları
- Lisans, yönetim, yedekleme ve taşıma bedelleri
Sık sorulan sorular
VDS her zaman fiziksel sunucudan daha ekonomik midir?
Hayır. İhtiyaç duyulan kaynak, lisans, yönetim ve yedekleme kapsamıyla toplam maliyet karşılaştırılmalıdır. Sürekli yüksek yükte fiziksel sunucu farklı bir maliyet yapısı sunabilir.
Kurumsal sunucu teklifine yedekleme dahil midir?
Hizmet kapsamına bağlıdır. Yedekleme sıklığı, saklama süresi, tutulduğu ortam ve geri yükleme sorumluluğu açıkça belirtilmelidir.
Sunucu yavaşsa doğrudan fiziksel sunucuya mı geçmeliyim?
Önce sorunun CPU, RAM, disk, ağ veya uygulama tarafında olup olmadığını ölçmek gerekir. Belirli bir sorgu ya da uygulama hatası fiziksel sunucuya taşınınca da devam edebilir. Geçiş kararı, ölçülen darboğaz ve uygulamanın gereksinimleriyle verilmelidir.
Teknik kaynaklar
Disket Teknoloji’nin sektör faaliyetleri 2014 yılında şahıs şirketi olarak başladı. Bugün hizmetlerimiz Disket Teknoloji Ltd. Şti. bünyesinde sürüyor. Şirket geçmişimiz.