Yurtdışı VDS Sunucu

Yurtdışı VDS'te ayrılmış kaynak neden daha değerli?

Diyelim ki yurt dışındaki kullanıcılarınızın en yoğun olduğu saatte ödeme sayfası iki saniyede açılmaya başladı. SSH ile bağlanıyorsunuz. Yük ortalaması normal, bellek boşta, ama sayfalar hâlâ ağır.

Bu sahnede ilk soru, yavaşlığın sunucudan mı yoksa yoldan mı geldiğidir. Sunucunun içinden bakınca yol görünmez, yolun üzerinden bakınca da sunucunun içi. İkisini birbirinden ayırmak için elinizde güvenebileceğiniz bir sabit olması gerekir.

Paylaşımlı kaynaklı bir sanal sunucuda o sabit yoktur, çünkü komşuların yükü işlemci sürenizi eksiltebilir. Linux bu kaybı steal time olarak raporlar. top çıktısındaki st değeri, sanal işlemcinizin çalışmaya hazır olduğu halde fiziksel çekirdeği beklediği zamanın oranıdır. VDS'te işlemci ve bellek size ayrıldığı için bu şüpheli büyük ölçüde listeden çıkar. Tamamen değil, bunu da dürüstçe söyleyelim. Disk altyapısı, ağ kartı ve üst bağlantı aynı makinedeki diğer sanal sunucularla hâlâ ortaktır. Yine de işlemci ve bellek tarafındaki belirsizlik kalkınca teşhis gerçek darboğaza çok daha çabuk iner. Steal değerini nasıl yorumlayacağınızı vCPU, çekirdek ve thread farkını anlattığımız yazıda bulabilirsiniz.

İkinci kazanç kıyaslanabilirlik. Teslim günü aldığınız ölçüm altı ay sonra da geçerli bir referanstır, çünkü aynı kaynak aynı sonucu vermeye devam eder. Paylaşımlı modelde aynı test farklı haftalarda farklı sonuç verebilir. Yerel bir sunucuda bu can sıkıcıdır. Oysa yurt dışındaki bir sunucuda bu, "yavaşlık ne zaman başladı, öncesinde değerler neydi" sorusuna cevap verememek demektir. Tahsis modelleri arasındaki farkı VPS ile VDS arasındaki fark yazısında ayrıntılı ele aldık.

Üçüncüsü muhatap. Yurt dışındaki bir sağlayıcıyla doğrudan çalıştığınızda arıza bildirimi çoğu zaman İngilizce, farklı bir saat diliminde ve o şirketin kurallarıyla yürür. Netx'te sunucu yurt dışında dursa da fatura Netx üzerinden TL kesilir, destek Türkçedir ve muhatabınız tektir. İki taraftan aldığınız ölçümleri aynı ekiple, aynı dilde konuşmak teşhisi kısaltır.

Yurt dışına satan mağazalar ve SaaS ekipleri

Yurt dışına açılan bir e-ticaret sitesinde ilk akla gelen çözüm, sunucuyu İstanbul'da bırakıp önüne bir CDN koymaktır. Yarım bir çözüm bu.

CDN görselleri, CSS ve JavaScript dosyalarını kullanıcıya yakın bir noktadan sunar. Sepet, arama, üye girişi ve ödeme adımı ise her seferinde kaynak sunucuya gider. Sayfayı üretmek için tarayıcı ile sunucu arasında birkaç gidiş-dönüş gerekiyorsa her biri mesafenin bedelini yeniden öder ve TCP ile TLS el sıkışmalarında bu bedel katlanır. Netx'in ölçümünde İstanbul içi gecikme yaklaşık 10 ms, Batı Avrupa lokasyonlarında ise 40–55 ms. Avrupa'daki bir müşteri İstanbul'daki sunucuya bağlanırken aynı farkı ters yönde yaşar. Bu farkın sayfa açılışına nasıl yansıdığını sunucu lokasyonu ile site hızı arasındaki ilişkiyi ölçtüğümüz yazıda hesapladık.

Avrupa VDS arayan mağazaların çoğu için doğru kurgu, dinamik istekleri karşılayan kaynak sunucuyu siparişin yoğunlaştığı bölgeye almak, statik içeriği yine CDN'e bırakmaktır. Ayrılmış kaynak kendini kampanya günü gösterir. Yurt dışı pazardaki indirim dönemleri Türkiye takvimiyle örtüşmeyebilir ve yükünüzün zirvesi sizin uyuduğunuz saate denk gelebilir. O saatte paylaşımlı bir sanal sunucunun size ne kadar işlemci süresi bırakacağını kimse bilemez. Paylaşımlı ortamın hangi noktada yetmediğini gösteren işaretleri e-ticarette VDS'e geçiş zamanı yazısında topladık.

SaaS tarafında hesap biraz farklı işler. Kurumsal müşteriler, özellikle Avrupa'dakiler, satın alma aşamasında verilerinin hangi bölgede tutulduğunu sık sık sorar. Bir bölgenin müşterilerini o bölgedeki bir yurtdışı VDS sunucuda toplamak gecikmeyi düşürür, bu soruya da net bir cevap verir. Yönetim panelini kullanan ekibiniz Türkiye'deyse onun yaşayacağı gecikmeyi de hesaba katın. Ara sıra açılan bir yönetim ekranında 40–55 ms fark edilmez. Gün boyu toplu kayıt işlenen ekranlarda edilir.

API sunucuları ve ülke IP'si isteyen işler

Sayfa açılırken fazladan 45 ms beklemek kimseyi üzmez. Aynı 45 ms tek bir işin içinde yirmi kez tekrarlanınca hesap değişir.

Uluslararası servislerle konuşan bir entegrasyon sunucusu düşünün. Pazar yerinden sipariş çekiyor, kargo firmasından etiket istiyor, ödeme sağlayıcısına durum soruyor. Bu çağrılar sırayla yapılıyorsa her gidiş-dönüş toplam süreye eklenir ve yirmi çağrılık bir zincirde 45 ms'lik gecikme tek başına 900 ms eder. Webhook alan uygulamalarda da benzer bir durum var. Karşı taraf yanıtınızı belli bir süre bekler, süre aşılınca isteği yeniden gönderir. Uygulamanız aynı olayı iki kez işlemeye karşı korunmuyorsa çift kayıt doğar.

VDS'in buradaki katkısı istikrar. Kuyruktan iş çeken arka plan işçileri işlemciyi uzun süre meşgul eder ve kaynak paylaşımlıysa aynı işin süresi gün içinde oynar. Süre oynadıkça zaman aşımı eşiklerini doğru kurmak zorlaşır. Eşik ya gereksiz yere geniş tutulur ya da yoğun saatte işler yarıda kesilir.

Belirli bir ülkenin IP adresini gerektiren üretim işleri ayrı bir başlık. Bazı ödeme ve pazar yeri servisleri yalnız izin listesine eklenmiş sabit IP'lerden gelen istekleri kabul eder, bazıları da erişimi ülkeye göre sınırlar. Bu işlerde IP adresi bir altyapı bileşeni gibi davranır ve değişmemesi gerekir. Teklif aşamasında adresin hizmet süresince sabit kalıp kalmayacağını, ek adres gerekirse nasıl tahsis edileceğini sorun. Burada bir parantez açalım. Ülke IP'si, karşı servisin kullanım koşullarının izin verdiği işler için anlamlıdır. Coğrafi kısıtlamayı aşmak amacıyla kurulan düzenler sözleşme ihlali riski taşır, IP adresini kara listelere de taşıyabilir.

İkinci lokasyonda ılık yedek olarak yurtdışı VDS

Felaket kurtarma planlarının en zayıf halkası çoğu zaman yedek sunucunun kendisidir. Aylarca boşta bekler, kimse ona bakmaz. İhtiyaç anında da kapasitesinin yetip yetmeyeceği belli değildir.

Ana sisteminiz Türkiye'deyse ikinci lokasyonu yurt dışında kurmak, tek bir bölgeyi etkileyen ağ, enerji ya da veri merkezi kaynaklı bir kesintinin etkisini sınırlar. Sıcak yedek canlı veriyle sürekli eşit tutulur ve kısa bir geçişle trafiği devralır. Ilık yedek de çalışır ve veriyi düzenli alır, ama devreye girmesi için elle birkaç adım gerekir. Soğuk yedekte ise yalnız veri kopyası vardır.

Bizce yurtdışı VDS en çok ılık ve sıcak yedekte anlam kazanır. Gerekçesi basit. Geçiş anı, ana lokasyonun gittiği ve bütün trafiğin aynı anda yedeğe yöneldiği andır. Paylaşımlı kaynaklı bir sanal sunucuda o an ne kadar işlemci bulacağınız komşuların o anki yüküne bağlıdır. Ayrılmış kaynakta ise provada ölçtüğünüz kapasite gerçek geçişte de karşınıza çıkar.

Planı yazıya dökün. Geçiş kararını kim verecek, hangi belirtiden sonra verecek? Geçiş DNS ile yapılacaksa ilgili kayıtların TTL değeri şimdiden 300 saniye gibi kısa bir değerde olmalı. Asıl tehlike ana lokasyon geri geldiğinde başlar. İki sunucu aynı anda yazma kabul ederse split-brain denen durum oluşur, siparişler bir tarafta, stok düşümleri öbür tarafta kalır ve iki ayrı gerçekliği elle birleştirmek zorunda kalırsınız. Eski ana sunucu bu yüzden yazmaya kapalı açılmalı, veri yeni ana sunucudan geriye doğru eşitlenmeli. Yılda en az bir kez gerçek bir geçiş provası yapılmadıysa elinizdeki şey plan değil, bir umuttur.

Yedek sunucuda alınan anlık görüntüler de tek başına yedekleme planı sayılmaz. Nedenini snapshot ile yedekleme arasındaki farkı anlattığımız yazıda bulabilirsiniz.

Aynı uygulama iki ülkede çalışacaksa veri nasıl eşitlenir?

Uygulama kodunu iki lokasyona kopyalamak kolaydır. Zor olan veri.

İlk karar, iki taraftan hangisinin yazma kabul edeceği. Aktif-pasif kurguda bütün yazmalar tek bir ana sunucuya gider, diğer taraf okuma hizmeti verir ya da bekler. Aktif-aktif kurguda iki taraf da yazar ve aynı kaydın iki yerde aynı anda değişmesi çakışma çözümü gerektirir. İşin pratiğinde, 40–55 ms'lik bir hatla ayrılmış iki lokasyonda aktif-aktif veritabanı çoğu ekip için gereksiz bir karmaşadır. Önerimiz tek yazıcı ve gerektiğinde yönü çevrilebilen bir replikasyon.

Dosyaları unutmayın. Veritabanı kusursuz eşitlense bile müşterinin yüklediği bir PDF ya da ürün görseli tek lokasyonda duruyorsa geçişten sonra kırık bağlantılarla karşılaşırsınız. lsyncd dosya sistemindeki değişiklikleri inotify ile izleyip rsync'i tetikler, böylece gecikme saniyeler düzeyinde kalır.

Oturum verisi de karar ister. Oturumlar Redis'te tutuluyor ve geçişte taşınmıyorsa kullanıcılar oturumdan düşer. Çoğu uygulamada bu kabul edilebilir bir bedel. Ödeme adımının ortasındaki bir müşteri için öyle değil.

Asenkron replikasyon RPO'yu nasıl belirler?

Asenkron replikasyonda RPO'yu bir yapılandırma dosyasında bulamazsınız. Onu ölçersiniz.

RPO, bir arızada kaybetmeyi kabul ettiğiniz verinin zaman cinsinden karşılığıdır. Asenkron modelde ana sunucu işlemi kaydeder, uygulamaya onay verir ve değişikliği arka planda karşı tarafa yollar. Ana sunucu tam o sırada giderse henüz karşıya ulaşmamış işlemler kaybolur. Yani RPO'nuz arıza anındaki replikasyon gecikmesine eşittir. Sakin bir günde bu gecikme bir saniyenin altında kalabilir. Toplu ürün içe aktarımı, büyük bir tabloya indeks eklenmesi ya da gece çalışan bir temizlik işi sırasında dakikalara uzayabilir.

Hat kapasitesi nadiren sorun çıkarır. Günde 20 GB ikili günlük (binlog) üreten bir veritabanı ortalamada saniyede yaklaşık 230 KB, yani 2 Mbit/s'nin biraz altında veri gönderir. Sıkıntı zirvelerde çıkar. Tek bir büyük işlem karşı tarafta da tek parça halinde uygulanır ve replika onu bitirene kadar arkasındaki her şey sırada bekler. MySQL'de paralel replikasyon işçileri (replica_parallel_workers) kuyruğu kısaltabilir. Daha garantili çözüm, toplu işlemleri küçük parçalara bölmektir.

Gecikmeyi izlemeden RPO'dan söz etmek boşunadır. MySQL'de SHOW REPLICA STATUS çıktısındaki Seconds_Behind_Source değeri ilk bakılacak yer, ama tek başına yanıltabilir. Bu değer replikanın elindeki günlükleri ne kadar geriden uyguladığını gösterir, ağ yüzünden henüz gelmemiş işlemleri görmez. Ana sunucuya her saniye zaman damgası yazan küçük bir heartbeat tablosu gerçek gecikmeyi verir, Percona Toolkit'teki pt-heartbeat bunu hazır yapar. PostgreSQL'de pg_stat_replication görünümündeki write_lag, flush_lag ve replay_lag sütunları aynı bilgiyi sunar. Değeri izleme sisteminize bağlayın ve bir eşik koyun. Örneğin 60 saniyeyi aşan gecikmede alarm üreten bir kural, RPO'nun bir varsayım olarak kalmasını önler.

Senkron seçeneğin bedelini de rakamla görelim. 45 ms'lik bir hatta her commit en az bir gidiş-dönüş bekler. Tek bağlantı üzerinden sırayla yazan bir uygulama bu durumda saniyede en fazla 22 civarında işlem yapabilir, 1.000 ms'yi 45'e bölünce çıkan sonuç bu. Eşzamanlı bağlantılar toplam sayıyı artırır, ama her kullanıcının beklediği süre yine uzar. Bu yüzden iki ülke arasında asenkron replikasyonu öneriyoruz. Birkaç saniyelik olası kaybı kabul edersiniz, karşılığında her işlem hızlı kalır.

Kişisel veri Türkiye'de, iş yükü yurt dışında

Sunucuyu yurt dışına koymak, kişisel veriyi yurt dışına aktarmak anlamına gelmek zorunda değil. Arayı açan şey mimari.

Önce çerçeve. Türkiye'deki kişilerin kişisel verilerini yurt dışındaki bir sunucuya koymak, 6698 sayılı Kişisel Verilerin Korunması Kanunu açısından çoğu durumda yurt dışına aktarım olarak görülür. Aktarım kuralları 2024'te yapılan değişiklikle yeniden düzenlendi. Kabaca anlatırsak, Kurul'un yeterlilik kararı varsa ona dayanılıyor, yoksa standart sözleşme gibi uygun güvencelerden biri gerekiyor. Lokasyon tarafındaki temel farkları yurt dışı VDS ile Türkiye lokasyonlu VDS'i karşılaştırdığımız yazıda topladık.

Karma mimaride kişisel veri Türkiye'deki sunucuda kalır, yurt dışındaki VDS kişisel veri içermeyen işleri üstlenir. Ürün kataloğu, fiyat ve stok servisleri, statik içerik, derleme ve test ortamları bu gruba girebilir. Kâğıt üzerinde temiz bir ayrım. Pratikte kişisel veri beklenmedik yerlerden sızar.

Web sunucusunun erişim günlükleri ziyaretçi IP adreslerini tutar ve IP adresi birçok durumda kişisel veri sayılır. Hata günlüklerine form içerikleri, e-posta kuyruklarına alıcı adresleri, önbellek ve oturum depolarına oturum açmış kullanıcının bilgileri düşebilir. Yurt dışındaki sunucu yalnız yedek olarak kurulmuş olsa bile ana veritabanının kopyasını alıyorsa aktarım fiilen gerçekleşir. Adı bir kodla değiştirilmiş, yani takma ad verilmiş veri de geri eşleştirilebildiği sürece kişisel veri sayılabilir. Gerçek anonimleştirme ayrı ve çok daha zahmetli bir iştir.

Açıkçası bu bölüm hukuki görüş değildir. Verinin hangi sistemde, hangi kopyada ve hangi günlükte durduğunu gösteren bir veri akış şeması çizin ve o şemayla hukuk danışmanınıza gidin. Aktarım dayanağı, sağlayıcıyla yapılacak sözleşme ve aydınlatma metninizde gereken değişiklik bu görüşmede netleşir.

Yurt dışı VDS kiralama tekliflerini nasıl kıyaslamalı?

Aylık bedel, bir teklifin size söylediği en az şeydir.

Teklifleri aynı terazide tartmak için her birini 12 aylık toplam maliyete çevirin. Bu toplama kira bedeli, varsa kurulum ücreti, ek IPv4 adresleri, işletim sistemi ve panel lisansları, yedekleme için ek depolama, standart kapsamın dışında kalan koruma hizmetleri ve isterseniz yönetim hizmeti girer. Bir teklifte olup ötekinde olmayan kalemi boş bırakmayın, piyasa fiyatıyla doldurun. İki rakam ancak o zaman aynı şeyi anlatır.

Döviz kalemi ayrı bir düşünce ister. Yurt dışındaki bir sağlayıcıdan doğrudan kiraladığınızda fatura çoğunlukla avro ya da dolar cinsinden gelir. Karttan çekilen tutar ödeme günündeki kura göre değişir, bankanız da yurt dışı işlem komisyonu ekleyebilir. Şirketseniz yurt dışından alınan hizmet için KDV'yi sorumlu sıfatıyla beyan etmeniz gerekebilir, bunu mali müşavirinizle konuşun. Netx'te yurtdışı VDS faturası TL olarak kesilir ve muhasebenizde yurt içi bir alım olarak işlenir. Şunu da saklamayalım. Yenilemede güncel fiyatlandırma geçerlidir ve yurt dışındaki altyapının maliyeti genellikle dövize bağlı olduğundan yenileme tutarı değişebilir. Kurun fiyatlara nasıl yansıdığını hosting fiyatlarında döviz riski yazısında anlattık.

IP adresleri ikinci sürpriz kaynağı. IPv4 kıt bir kaynak olduğu için ek adresler genellikle ücretlendirilir, kullanım gerekçesi de istenebilir.

Lisansa gelince, Linux kullanıyorsanız ödenecek bir bedel yok. Windows Server istenirse Netx lisans bedelini teklife ekler. Sunucuya yönetim dışında kullanıcılar da uzak masaüstüyle bağlanacaksa ya da aynı anda ikiden fazla oturum gerekecekse RDS CAL lisansları da gerekir, çünkü Windows Server ek lisans olmadan yalnız yönetim amaçlı ve en fazla iki eşzamanlı oturuma izin verir. Panel kullanacaksanız onun lisansı da teklifte ayrı bir satır olarak görünmeli. İşletim sistemi tercihinin maliyet ve yönetim tarafını Linux VDS mi, Windows VDS mi yazısında karşılaştırdık.

Teklif formuna ne yazmalı?

Formda boş bıraktığınız her alanı sizin yerinize biri tahmin edecek demektir.

Hedef bölgeyle başlayın, ama yalnız bölge adı yazmayın. Kullanıcılarınızın ülke dağılımını, analitik aracınızdaki oranlarla birlikte iletin. Aklınızda belirli bir ülke ya da şehir varsa nedenini de ekleyin, çünkü son kullanıcıya yakınlık ile bir ödeme sağlayıcısına yakınlık farklı lokasyonları işaret edebilir. Netx lokasyon seçeneklerini hedef bölgenize ve ihtiyacınıza göre teklif aşamasında paylaşır.

Elinizde çalışan bir sunucu varsa onun gerçek kullanım verisi, tahminle seçilmiş bir paketten çok daha değerlidir. Son 30 günün işlemci ve bellek grafiğini, en yoğun saatteki yükü, disk doluluğunu ve aylık trafik hacmini çıkarın. Sıfırdan kuruyorsanız iş yükünü tarif edin. Hangi uygulama, hangi veritabanı, kaç eşzamanlı kullanıcı? vCore ve RAM hesabının yöntemini iş yüküne göre VDS kaynak hesaplama yazısında anlattık, burada tekrar etmeyelim. Bunların yanına şu bilgileri de koyun.

• Kaç IP adresine ihtiyacınız olduğu ve her birinin ne için kullanılacağı.
• İşletim sistemi ve sürümü, Windows ise uzak masaüstüyle aynı anda bağlanacak kişi sayısı.
• Panel isteyip istemediğiniz, istiyorsanız hangisi.
• Türkiye'deki sistemle eşitleme yapılacaksa veritabanı türü, eşitlemenin yönü ve kabul ettiğiniz veri kaybı süresi.
• Yedeğin nerede duracağı ve taşımayı kimin yapacağı.
• Sunucuda kişisel veri işlenip işlenmeyeceği.

Netx bu bilgilere göre uygun lokasyonu, yapılandırmayı, fiyatı ve teslim süresini yazılı teklifle bildirir. Onayınızdan sonra güvenlik ve doğru hizmet için sizinle iletişime geçilir, kurulum ondan sonra başlar. O görüşmeyi formalite saymayın. Formda eksik kalan teknik ayrıntıları kapatmak için iyi bir fırsattır. Hazırsanız sayfadaki teklif formunu doldurabilirsiniz.

Taşıma ve devreye alma sırası

Yurt dışına taşımanın tek farkı mesafedir. Ama o fark her adıma biraz zaman ekler.

Tek bir TCP bağlantısının hızı gecikmeyle sınırlı olduğu için büyük aktarımları paralel akışlara bölmek süreyi kısaltır. Bu yüzden ilk kopyayı geçiş gününden günler önce alın, son gün yalnız farkı aktarın. Önerdiğimiz sıra şöyle.

1. Geçişten önce DNS kayıtlarının TTL değerini 300 saniyeye çekin. Bunu en az eski TTL süresi kadar önce yapın, 86.400 saniyelik bir TTL için bu bir gün önce demek.
2. Yeni sunucuyu teslim alıp sertleştirin, uygulamayı ve bağımlılıklarını kurun.
3. Dosyaların ilk kopyasını rsync ile alın. Veritabanı için yeni sunucuyu mevcut sunucunun replikası olarak bağlayın. Bu mümkün değilse döküm alıp geri yükleyerek en az bir prova yapın.
4. Kendi bilgisayarınızın hosts dosyasına yeni IP'yi yazıp siteyi yeni sunucu üzerinden gezin. Ödemeyi, e-posta gönderimini ve zamanlanmış görevleri tek tek deneyin.
5. Geçiş anında eski sistemi bakım moduna alıp yazmayı durdurun, replikasyonun yetiştiğini doğrulayın ve son rsync'i çalıştırın.
6. Yeni sunucuyu ana sunucu yapın, DNS kayıtlarını yeni IP'ye çevirin.
7. Eski sunucuyu hemen kapatmayın. Birkaç gün yazmaya kapalı halde bekletin, geç gelen istekleri ve unutulmuş zamanlanmış görevleri günlüklerden izleyin.
8. İki lokasyonlu bir yapı hedefliyorsanız eski sunucuyu silmek yerine replikasyonun yönünü çevirip onu ılık yedek olarak bırakmayı düşünün. Taşıma için kurduğunuz düzen böylece boşa gitmez.

Taşımayı kendiniz yapmayacaksanız formda belirtin. Kapsamını ve varsa ücretini teklifte yazılı görmek, geçiş günü sürprizle karşılaşmamanın en kolay yolu.

Teslim günü kendi ölçümünüzü alın

Erişim bilgileri e-postanıza geldiğinde uygulamayı kurmadan önce bir saatinizi ölçüme ayırın. Boş bir sunucuda alınan sonuçlar, ileride çıkacak her performans tartışmasında elinizdeki en tarafsız referanstır.

İşlemci için sysbench yeter. sysbench cpu --threads=4 --time=60 run komutu saniyedeki olay sayısını (events per second) verir. Thread sayısını size ayrılan vCore sayısına eşitleyin, sonra bir de tek thread ile çalıştırın. Ayrılmış kaynakta bu değerlerin gün içinde pek oynamaması gerekir. Test sürerken ikinci bir terminalde vmstat 1 açıp st sütununu izleyin. Sıfıra yakın kalmasını beklersiniz.

Disk tarafında fio kullanın. Teklifte yazan disk sınıfını doğrulamanın en pratik yolu 4K bloklarla rastgele okuma ve yazma testidir. fio --name=rr --rw=randread --bs=4k --iodepth=32 --numjobs=4 --size=2G --runtime=60 --time_based --direct=1 --ioengine=libaio --group_reporting çıktısında IOPS'un yanında gecikme yüzdeliklerine (clat percentiles) de bakın. Ortalaması iyi, 99. yüzdeliği kötü olan bir disk veritabanında ara ara takılma olarak hissedilir. --direct=1 parametresi işletim sisteminin önbelleğini devre dışı bırakır. Onsuz alınan sonuç disk yerine belleği ölçer.

Ağ için iperf3 kullanın. Türkiye'deki sunucunuzda iperf3 -s ile bir dinleyici açın, yurt dışındaki VDS'ten iperf3 -c tr-sunucu -P 4 -t 30 ile bağlanın, sonra komutun sonuna -R ekleyip ters yönü ölçün. İki lokasyon arasında replikasyon ya da yedek aktarımı planlıyorsanız asıl işinize yarayacak sayı budur, çünkü sizin trafiğiniz tam olarak bu hattan geçecek. iperf3 varsayılan olarak 5201 numaralı TCP portunu kullanır, test bitince güvenlik duvarında açtığınız izni kapatın.

Testleri sabah, akşamın yoğun saatinde ve gece olmak üzere en az üç kez tekrarlayın, sonuçları tarih, saat ve parametreleriyle kaydedin. Sonuçların nasıl yorumlanacağını sunucu performans testi rehberinde anlattık.

Ağı iki yönden okuyun, IP adresini teslim günü tarayın

İnternet trafiği gittiği yoldan dönmek zorunda değildir.

Türkiye'den yurt dışındaki sunucuya giden paketler bir taşıyıcının ağından, dönüş paketleri bambaşka bir taşıyıcının ağından geçebilir. Buna asimetrik yönlendirme denir ve tek yönlü ölçüm sorunun yarısını gizler. Ofisinizden mtr -rwz -c 100 sunucu-ip çalıştırdıktan sonra aynı komutu sunucudan ofisinizin IP adresine doğru da çalıştırın. -z seçeneği durakların AS numarasını gösterir, trafiğin hangi ağlardan geçtiğini böylece görürsünüz. Bir ara durakta görünen ama sonraki duraklara yansımayan paket kaybı genellikle o yönlendiricinin ICMP'ye düşük öncelik vermesinden gelir. Gerçek kayıp hedefe kadar taşınır. Teklif öncesinde test IP'siyle gecikme ölçmeyi ve traceroute çıktısını yorumlamayı yurt dışı kiralık sunucu sayfamızdaki rehberde adım adım anlattık.

IP adresinin kendisi de teslim günü kontrol edilmeli. İlk soru coğrafi konum. Bir servis IP'nizin hangi ülkeden geldiğine karar verirken kendi GeoIP veritabanına bakar. Bu veritabanları birbirinden bağımsız güncellenir ve bir blok el değiştirdiğinde biri yeni ülkeyi gösterirken öteki haftalarca eskisini göstermeye devam edebilir. whois sunucu-ip çıktısındaki country satırını ve en az iki ayrı GeoIP sorgusunu karşılaştırın. Ülke bazlı erişim isteyen bir servisle çalışacaksanız bu kontrolü yapmadan üretime geçmeyin.

İkinci soru itibar. Adres sizden önce başka biri tarafından kullanıldıysa Spamhaus gibi kara listelerde kalmış olabilir. Sunucudan e-posta gidecekse ters DNS (PTR) kaydının sunucunun ana makine adını göstermesini isteyin ve 25 numaralı portun çıkışa açık olup olmadığını sorun. Kara listeden çıkma ve gönderici itibarı konusunu e-postaların neden spama düştüğünü anlattığımız yazıda ele aldık.

Root sizde, sorumluluk da

Root erişimi bir yetki olduğu kadar bir iş tanımıdır.

Netx'in yurtdışı VDS sunucularında Linux'ta root, Windows Server'da yönetici yetkisi size verilir. İşletim sistemi güncellemeleri, güvenlik duvarı, yedekler ve izleme de bu yüzden sizin elinizdedir. Sunucu yurt dışındayken bu yük biraz ağırlaşır, çünkü oradaki kullanıcılarınızın yoğun saati sizin mesainize denk gelmeyebilir ve gece gelen bir alarmı kimin karşılayacağı belirsiz kalabilir.

İlk günün işleri belli. SSH'ta parola yerine anahtarla giriş, root ile doğrudan girişin kapatılması, varsayılan olarak her şeyi reddeden bir güvenlik duvarı, otomatik güvenlik güncellemeleri ve fail2ban. Windows'ta uzak masaüstü portunu internete açık bırakmamak ve hesap kilitleme ilkesini etkinleştirmek aynı listenin parçasıdır. Linux tarafındaki adımları Linux sunucu ilk kurulum ve güvenlik rehberinde sıraladık.

Bu işleri kendiniz yürütmek istemiyorsanız sunucu yönetimi hizmetini ayrıca alabilirsiniz. Bizce karar tek bir soruya dayanır. Ekibinizde güncellemeleri, yedek doğrulamasını ve güvenlik uyarılarını düzenli olarak takip edecek biri var mı? Cevap hayırsa yönetimi devretmek, uzaktaki bir sunucuda yerel bir sunucuda olduğundan daha çok anlam taşır.

Yurtdışı VDS mi, yurtdışı VPS mi, yurt dışı dedicated mı?

VDS'in açılımı Virtual Dedicated Server. Hizmet bu yüzden kimi zaman yurtdışı sanal dedicated sunucu adıyla da aranır, ama ad yanıltmasın, kiraladığınız şey fiziksel bir makine değil, onun size ayrılmış bir dilimidir. Tipik iş yüklerinde tablo şöyle oluşuyor.

Tablodaki sınırlar kesin değil. Düşük hacimli bir API sunucusu VPS'te rahat çalışabilir, büyüyen bir mağaza da bir gün fiziksel sunucuya geçebilir. Sınıf değiştirme zamanını genelde sunucunun kendisi söyler. Sanal sunucuda steal değeri yoğun saatlerde sürekli yükseliyorsa ayrılmış kaynağa, VDS'te disk bekleme süresi (iowait) kalıcı olarak yüksekse fiziksel sunucuya bakma zamanı gelmiştir. Netx bu üç sınıfı da yurt dışı lokasyonda teklif usulüyle sunuyor. Maliyet önceliğiniz varsa yurtdışı VPS sunucu seçeneğine, donanımın tamamını istiyorsanız yukarıda andığımız yurt dışı kiralık sunucu sayfasına bakın. Kullanıcılarınızın çoğu Türkiye'deyse belki hiçbirine gerek yoktur, Türkiye lokasyonlu VDS sanal sunucu paketleri onlara daha düşük gecikme verir.

En sık gördüğümüz yanlışlar

Yanlışların çoğu sunucu teslim edilmeden, teklif yazışmasında yapılır.

Listenin başında, kullanıcıları Türkiye'de olan bir siteyi somut bir gerekçe olmadan yurt dışına taşımak var. Netx'in ölçtüğü değerlerle bu, Türkiye'deki her ziyaretçinin her gidiş-dönüşüne 30–45 ms eklemek demek ve karşılığında elde edilen bir şey yoktur. Onu, teklifleri yalnız aylık bedelle kıyaslamak izler. Windows lisansı, RDS CAL, panel lisansı ve ek IP satırları ilk faturada ortaya çıkar.

İki lokasyonlu kurgularda hata başka yerden gelir. Replikasyon aylarca çalışıyor görünür, kimse gecikmeyi izlemez. İlk gerçek geçişte yalnız ana sunucuda tanımlı bir veritabanı kullanıcısının, bir zamanlanmış görevin ya da eşitlenmeyen bir yükleme klasörünün unutulduğu anlaşılır.

Teslim günü ölçüm almamak, sonraki her performans şikâyetini elde kıyaslayacak bir şey olmadan tartışmak demektir. KVKK değerlendirmesini canlıya geçtikten sonra yapmak ve erişim günlüklerindeki IP adreslerini unutmak da bu listeye girer.

Bir de ılık yedeğin kaderi var. Aylarca dokunulmayan bir sunucunun faturası da unutulabilir. Netx sözleşmesine göre ödenmeyen hizmet vadeden 5 gün sonra durdurulur, sonraki 15 gün içinde veriler silinebilir. Yedek sunucunun fatura bildirimlerinin güncel ve takip edilen bir e-posta adresine gittiğinden emin olun.

Teklif istemeden önce son kontrol

Aşağıdaki maddelerin her birine yazılı bir cevabınız varsa teklif isteğiniz hazır demektir. Boş kalan madde varsa onu teklif görüşmesindeki ilk sorunuz yapın.

• Sunucunun neden yurt dışında olması gerektiği, kullanıcı dağılımıyla birlikte tek cümlede yazılı.
• Hedef bölgedeki kullanıcı ağlarından ve Türkiye'den gecikme ölçümü yapıldı.
• vCore, RAM ve disk ihtiyacı mevcut sistemin gerçek kullanım verisine dayanıyor.
• Teklifteki disk türü ve sınıfı yazılı, teslim günü fio ile doğrulanacak.
• IP adedi, adreslerin sabit kalıp kalmayacağı ve ek IP koşulu netleşti.
• Windows Server lisansı, RDS CAL ve panel lisansı teklifte ayrı satırlar olarak görünüyor.
• Türkiye'deki sistemle eşitleme yöntemi, yönü ve kabul edilebilir RPO belirlendi.
• Replikasyon gecikmesi için alarm eşiği konuldu, ilk geçiş provasının tarihi takvimde.
• Kişisel veri akış şeması çizildi, aktarım dayanağı hukuk danışmanıyla konuşuldu.
• Sunucu yönetiminin sizde mi kalacağı, ayrıca hizmet mi alınacağı kararlaştırıldı.
• %99,9 uptime taahhüdünün 30 günlük bir ayda yaklaşık 43 dakikalık kesinti payı anlamına geldiği ve planlı bakımın bu hesaba nasıl girdiği konuşuldu.