VPS Nasıl Taşınır: Yeni Bir Sunucuya Kesintisiz Geçiş

Çoğu taşıma işlemi kopyalama sırasında başarısız olmaz. Bunlar, DNS değişikliğinden sonraki yirmi dakika içinde başarısız olur — internetin yarısı hâlâ eski sunucuyla konuşurken, diğer yarısı zaten yeni sunucuya geçmiştir ve her iki makine de yazma isteklerini kabul etmektedir. Dosyalar eksiksiz ulaşmıştır, site açılmaktadır ve yine de siparişler, hiçbir zaman uzlaştırılmayacak iki ayrı veritabanına düşmektedir. Bunu önlemek, aktarım hızıyla neredeyse hiç ilgili değildir; sıralamayla ise neredeyse her şeyiyle ilgilidir: önce neyi değiştirdiğiniz, neyi dondurduğunuz ve emin olana kadar neyi çalışır durumda tuttuğunuz.

Kesintisiz taşımanın gerçek anlamı

Kesin olmakta fayda var, çünkü bu ifade birbirinden çok farklı iki vaadi kapsar ve bunların maliyeti de birbirinden çok farklıdır. Hangisini satın aldığınıza karar vermek, taşımanın ilk gerçek kararıdır.

Birinden vazgeçmeniz gerekiyorsa, erişilebilirlikten vazgeçin. Dört dakikalık bir bakım sayfası açıklayabileceğiniz bir şeydir. Birbirinden sapmış veri ise düzeltemeyeceğiniz bir şeydir, çünkü hangi kopyanın doğru olduğunu söyleyecek hiçbir otorite kalmamıştır.

Kopya almadan önce envanter çıkarın

Bir sunucu, kimsenin belgelemediği şeyler biriktirir: bir olay sırasında eklenen bir cron işi, bir ortağın adresi için bir güvenlik duvarı kuralı, bir servis dosyasına yapıştırılmış bir API anahtarı. Kopya bunları taşımaz ve siz bunları önümüzdeki iki hafta boyunca teker teker keşfedersiniz. Şimdi ayrılacak yarım saatlik bir envanter çalışması, bunların neredeyse tamamını ortadan kaldırır.

Bunu bir terminal kaydırma geçmişine değil, sürüm kontrolünde tuttuğunuz bir dosyaya yazın. Geçiş sırasında bunu üç kez okuyacaksınız — biri de net düşünemediğiniz bir anda.

Hedefi, daha sonra değiştiremeyeceğiniz şeylere göre seçin

Teknik özellikler ayarlanabilir; birkaç özellik ise ayarlanamaz ve bunlara, elinizde hâlâ özgür bir seçim varken bilinçli olarak karar vermeye değer. Zaten taşınıyor olduğunuza göre, bu, etrafından dolaşıp durduğunuz bir kısıtlamayı düzeltmek için elde edeceğiniz en ucuz andır.

• Konum, çünkü kullanıcılarınıza olan gecikme de geçerli hukuk da bununla belirlenir. /locations, bölgeleri ve bunların gidiş-dönüş özelliklerini listeler; ayrıldığınız yerden bağımsız olarak başarısız olacak birini seçin.
• Hukuki zemin, taşınma nedeniniz mevcut sağlayıcınızın şikâyetleri paketlerden daha hızlı iletmesiyse. /offshore-hosting, yargı alanının gerçekte neyi kontrol ettiğini ve neyi kontrol etmediğini ortaya koyar.
• Faturalandırma kimliği, çünkü ödemeyi kabul etmeden önce belge isteyen bir sağlayıcının, yapısı gereği sizinle ilgili bir dosyası vardır. /no-kyc-vps ve /pay-with alternatifi anlatır — kriptoyla doldurulmuş bir bakiye, kart yok, makineye bağlı isim yok.
• Büyüme payı, çünkü iki kez taşınmak kimsenin planlamadığı bir sonuçtur. /vps planları listeler ve mevcut makineniz hiç gerçekten ölçülmediyse /guides boyutlandırma yöntemini sunar.
• IPv6 ve temiz bir IPv4, çünkü geri dönüştürülmüş bir adres, başka birinin itibarını da beraberinde taşıyor olabilir — bu bir posta sorununa dönüşmeden önce kontrol edin.

Önce, günler öncesinden DNS TTL'sini düşürün

Bu, sonda aceleye getirilemeyecek tek hazırlık adımıdır, çünkü etkisi kontrol etmediğiniz bir saate bağlıdır. Kayıtlarınızdaki TTL, çözümleyicilere bir yanıtı ne kadar süreyle önbelleğe alacaklarını söyler. Bir gün olarak ayarlanmışsa, bir saat önce sorgu göndermiş bir çözümleyici, ne yayınlarsanız yayınlayın önümüzdeki yirmi üç saat boyunca kullanıcıları eski sunucuya göndermeye devam eder.

1. 1

   Mevcut TTL'yi okuyun

   dig +noall +answer yourdomain.com kalan önbellek süresini gösterir; yetkili ad sunucunuzu doğrudan dig @ns1.example.net yourdomain.com ile sorgulamak ise yapılandırılmış değeri gösterir. Bunu not edin — bekleme süreniz bu sayıya göre belirlenir.

2. 2

   300 saniyeye düşürün

   Değişecek her kayıttaki TTL'yi düşürün: A, AAAA ve sunucuyu gösteren her MX ya da CNAME. Beş dakika, geçişi rahat kılacak kadar kısa, ad sunucularınızı yormayacak kadar da uzundur.

3. 3

   Eski TTL'nin bitmesini bekleyin, ardından bir kez daha bekleyin

   Yeni, kısa TTL bir çözümleyiciye ancak eski, uzun TTL süresi dolduktan sonra ulaşır. Düşük TTL'yi gerçek saymadan önce en az bir tam eski-TTL süresi bekleyin — bir gündü ise bir gün. Buna erken başlamanın hiçbir maliyeti yoktur ve tüm geçişe bir güvenlik payı kazandırır.

Yeni sunucuyu kurun, eskisini klonlamayın

İçgüdü, mevcut diskin imajını alıp başka bir yerde geri yüklemektir. Bu, tıpkı bir geri yüklemede olduğu gibi yanlış bir harekettir: blok düzeyinde bir klon, yapılandırma sapmasını, sahipsiz paketleri, birinin yarım bırakıp terk ettiği servisi ve önceki bir saldırganın bırakmış olabileceği her türlü kalıcılık mekanizmasını sadakatle yeniden üretir. Ayrıca sizi eski dağıtım sürümüne de sabitler.

Yeni makineyi güncel bir taban imajından kurun, servisleri bir betikten yükleyin ve yalnızca veriyi kopyalayın. Asıl teslim edilen ürün betiğin kendisidir — bir sonraki taşımayı iki hafta yerine bir öğleden sonraya dönüştüren de, bir olaydan sonra arkeoloji yapmadan yeniden kurmanızı sağlayan da odur.

• Başka her şey ona dokunmadan önce sağlayın, güncelleyin ve sıkılaştırın: yalnızca anahtarla SSH erişimi, varsayılanı reddeden bir güvenlik duvarı, gözetimsiz güvenlik güncellemeleri. /guides, bu kontrol listesinin bir saatlik ayrıntılı sürümünü sunar.
• Çalışma zamanının ve veritabanının, üretimle aynı ana sürümlerini kurun. Bir taşıma, aynı zamanda PostgreSQL'i 14'ten 17'ye yükseltmek için de kötü bir zamandır — her seferinde tek bir değişiklik yapın, böylece bir hatanın tam olarak tek bir açıklaması olur.
• Dosyaları kopyalamadan önce kullanıcıları ve grupları aynı sayısal kimliklerle yeniden oluşturun, ya da sahipliği sonradan elle düzeltin. --numeric-ids ile aktarmak sayıları olduğu gibi korur; bunları doğru adlarla eşleştirmek ise size düşer.
• Yeni adresi, hâlâ ikisi de geçerliyken, şu anda eskisini adlandıran her izin listesine ekleyin — ortak API'ler, yönetilen veritabanı güvenlik duvarları, ödeme ağ geçitleri, kendi izlemeniz.

Dosyaları iki geçişte kopyalayın

Canlı bir dosya sisteminin tek bir aktarımı, hareketli bir hedefin anlık görüntüsüdür. İki geçiş bunu temiz bir şekilde çözer: birincisi uzun sürer ve canlı bir sistem üzerinde çalışır, ikincisi kısadır ve dondurma sırasında çalışır — hızlı olması gereken de yalnızca ikincisidir.

İlk geçişi istediğiniz zaman çalıştırın — günler öncesinden yapmak sorun değildir. Büyük kısmı taşır: yüklemeler dizini, posta kuyruğu, konteyner birimleri, yıllar içinde birikmiş medya. Geçiş yaptığınızda güncelliğini yitirmiş olacaktır ve ikinci geçişin amacı tam olarak budur.

• SSH üzerinden rsync -aAXH --numeric-ids --info=progress2 kullanın: olağan öznitelikler için -a, ACL'ler için -A, genişletilmiş öznitelikler için -X, makinede yinelenenlerden arındırma yapan bir şey varsa önem taşıyan sabit bağlantılar için -H.
• Taşınmaması gerekeni hariç tutun: /proc, /sys, /dev, /run, geçici dizinler, paket önbelleği ve ihtiyacınız olmayan günlükler. Çekirdek arayüzlerini kopyalamak, en iyi ihtimalle zaman kaybettirir, en kötü ihtimalle aktarımı kilitler.
• --delete bayrağını yalnızca ikinci geçişte ekleyin. Birincisinde zararsızdır; ikincisinde ise o zamandan beri kaynakta silinmiş dosyaları kaldırır ki ortadan kaldırmaya çalıştığınız sapma tam olarak budur.
• Sistem yapılandırmasını topluca değil, seçerek kopyalayın. İstediğiniz şey web sunucunuzun vhost tanımları, servis birimleriniz ve uygulama yapılandırmanızdır — eski makinenin dosya sistemi tablosu, ağ yapılandırması ya da makine kimliği değil.
• Aktarım için tek kullanımlık bir SSH anahtarı üretin, hedefte yetkilendirin ve taşıma bittiğinde kaldırın. İki yıl boyunca ortalıkta kalan bir taşıma anahtarı, kimsenin verdiğini hatırlamadığı bir kimlik bilgisidir.

Geçişler arasında varsaymak yerine doğrulayın. İkinci geçişi --dry-run ile çalıştırmak neyi değiştireceğini tam olarak yazdırır: birkaç yüz güncel dosyalık bir liste sağlıklıdır, kırk bin dosyalık bir liste ise bir hariç tutmanın yanlış olduğu ya da bir şeyin sebepsiz yere zaman damgalarını yeniden yazdığı anlamına gelir.

Veritabanını yazma kaybetmeden taşıyın

Dondurma bütçesinin harcandığı yer burasıdır ve doğru teknik tamamen başlangıçta yazdığınız sayı tarafından belirlenir. Aşağıdaki üç seçeneğin hepsi doğrudur — farklı sayılar için.

Veri kümesi büyük olduğunda şemayı ve veriyi ayrı ayrı döküm alın. Önce şemayı geri yüklemek, yapının, indekslerin ve izinlerin yeni sunucuda erkenden doğrulanmasını sağlar; bu da veri yüklemesini, dondurma sırasında zaten sorunsuz sonuçlanacağından emin olarak başlatabileceğiniz tek uzun bir işleme dönüştürür.

TLS sertifikasını değişiklikten sonra değil, önce çıkarın

Yeni sunucudaki sertifika, ilk kullanıcının geldiği anda geçerli olmalıdır. Bunun tersini geçiş sonrasında keşfetmek, her ziyaretçinin bir tarayıcı uyarı ekranıyla karşılaşması demektir ve HSTS başlıkları gönderiyorsanız — ki göndermelisiniz — bunu tıklayıp geçemezler bile. DNS herhangi bir yeni yeri göstermeden önce elinizde çalışan bir sertifika bulundurmanın iki yolu vardır.

• Mevcut olanı kopyalayın. Bütün ACME durum dizinini, ya da yalnızca istemcinizin sertifika ve anahtarı sakladığı yerden ikisini. Anında geçerlidir, çünkü geçerlilik, dosyayı hangi sunucunun tuttuğuyla hiç ilgili değildir ve DNS taşındığında yenileme normal şekilde devam eder.
• DNS-01 doğrulamasıyla yeni bir sertifika çıkarın; bu, alan adının kontrolünü, mevcut adrese yapılan bir HTTP isteği yerine bir TXT kaydıyla kanıtlar. Bu, taşımadan önce, geçişten önce ve HTTP-01'in hiç yapamadığı wildcard'lar için de çalışır.
• Değişiklikten önce yeni sunucuda HTTP-01 doğrulaması denemeyin. Doğrulama, alan adı üzerinden 80 numaralı porttan getirilir, alan adı hâlâ eski makineye çözümlenir ve doğrulama her seferinde başarısız olur.

Tek bir komutla, ana bilgisayar adını yeni adrese çözümleyerek, DNS'e hiç dokunmadan doğrulayın: curl -sI --resolve yourdomain.com:443:198.51.100.10 https://yourdomain.com/ — gerçek adresi yerine koyarak. Bu tek satır, bütün taşımadaki en yüksek değerli kontroldür. Yeni makinedeki gerçek vhost'u, gerçek sertifikayı ve gerçek uygulama yığınını çalıştırır ve yanlış yapılandırmayı, bulmanın hâlâ hiçbir maliyeti yokken bulmanızı sağlayan da odur.

Sunucu posta gönderiyorsa, daha erken başlayın

Posta, bir taşımanın günler sonra sessizce başarısız olan ve başka bir şeyin suçlandığı parçasıdır. Yeni bir adresin gönderim itibarı yoktur ve başkasınınkini devralmış olabilir; yayınladığınız her kimlik doğrulama kaydı da ayrıldığınız adrese bağlıdır.

• Yeni adresi, üzerinde karar kılmadan önce başlıca kara listelere karşı kontrol edin. Geçmişi olan geri dönüştürülmüş bir IP, değiştirmek hâlâ bedavayken değiştirmeye değer.
• Yeni adresteki ters DNS kaydını posta ana bilgisayar adınıza ayarlayın. Alıcı sunucular, ileri ve ters çözümlemenin birbiriyle uyuştuğunu kontrol eder ve eksik bir PTR, tek başına spam olarak işaretlenmeye yeter.
• Geçişten önce yeni adresi SPF'ye ekleyin, sonrasında ise eskisini kaldırın — örtüşme sırasında ikisi de listelenir, böylece postayı gerçekte hangi sunucu gönderdiyse ondan kimlik doğrulaması yapılır.
• Yeni anahtarlar oluşturmak yerine DKIM özel anahtarlarını kopyalayın, böylece DNS'te zaten yayınlanmış olan seçici (selector) doğrulamaya devam eder. Yeniden oluşturmak yeniden yayınlamak demektir ve yeniden yayınlamanın da kendi yayılma gecikmesi vardır.
• Herhangi bir hacimde gönderim yapıyorsanız yeni adresi kademeli olarak ısıtın. Var olduğu süre boyunca hiçbir şey göndermemiş, sonra birden on bin mesaj yayan bir sunucu, bir alıcı için ele geçirilmiş bir sunucudan ayırt edilemez.

Geçiş anı

Yukarıdakilerin hepsi, bu kısmın kısa, sıralı ve geri alınabilir olması için yapılan hazırlıktı. Bunu, boş inanç yüzünden sabahın 3'ünde değil, gerçek trafiğinizin en düşük olduğu anda yapın — kendi analitiğinizi kontrol edin. Başlamadan önce geri alma planını yazıya dökün, çünkü ona ihtiyaç duyacağınız an, onu en az yazmak isteyeceğiniz andır.

1. 1

   Eski sunucuda yazmaları dondurun

   Bakım modu, salt okunur bir veritabanı kullanıcısı, ya da ters proxy'de yazma yollarında bir hata. Okumalar, süreç boyunca eski makineden sunulmaya devam eder — veri taşınırken siteyi ayakta tutan da budur.

2. 2

   Eski sunucudaki her zamanlayıcıyı devre dışı bırakın

   crontab'ları yorum satırına alın, zamanlayıcıları durdurun, kuyruk işçilerini durdurun. Bu noktadan itibaren eski makine hiçbir şeyi işlememelidir, yoksa işler iki kez çalışır: iki fatura, iki e-posta, iki webhook teslimatı.

3. 3

   Son farkı çalıştırın

   --delete ile ikinci dosya geçişi, ardından son veritabanı dökümü ya da replikanın yetişmesi. Bu, kısa olanıdır, en fazla birkaç dakika sürer, çünkü hacmi zaten ilk geçiş taşımıştır.

4. 4

   Yeni sunucuyu gerçek ana bilgisayar adına karşı doğrulayın

   Yukarıdaki --resolve numarasını kullanarak, veritabanından okuyan bir sayfayı, bir girişi ve bir yazma yolunu çalıştırın. Satır sayılarının kaynakla eşleştiğini doğrulayın. Bütün bunları, DNS değişmeden önce, geri almanın hâlâ hiçbir maliyeti yokken yapın.

5. 5

   DNS'i değiştirin ve servisleri başlatın

   A ve AAAA kayıtlarını yeni adrese güncelleyin, ardından uygulamayı ve zamanlayıcılarını yeni sunucuda etkinleştirip başlatın. Trafik bir TTL süresi içinde gelmeye başlar ve önümüzdeki saat boyunca kaymaya devam eder.

6. 6

   Eski sunucuyu okumalara açık tutun

   En az yirmi dört saat boyunca onu ayakta ve salt okunur bırakın. Bayat önbelleğe sahip istemciler hâlâ ona ulaşacaktır ve salt okunur eski bir sunucu, reddedilen bir bağlantı yerine biraz bayat sayfalar döndürür — görünmez bir taşıma ile görünür bir taşıma arasındaki fark de budur.

İlk 48 saat

Site açıldığında taşıma bitmiş sayılmaz. Eski makineye artık hiçbir şey bağımlı olmadığında biter ve bu bağımlılıkları bulmak, beklemeye dayalı bir oyun değil, etkin bir çalışmadır.

• Eski sunucunun erişim günlüğünü izleyin. Oraya hâlâ ulaşan her istek, taşınmamış bir bağımlılıktır — bir ortak entegrasyonundaki sabit kodlanmış bir adres, bayat önbelleğe sahip bir mobil istemci, kimsenin sahiplenmediği bir izleme probu. Günlük, yapılacaklar listenizdir.
• Zamanlayıcıların yeni sunucuda gerçekten çalıştığını doğrulayın. Etkin olduklarını değil — beklenen zamanda, beklenen çıktıyla çalıştıklarını. Sessizce hiçbir şey yapmayan bir cron işi, çalışan bir cron işiyle birebir aynı görünür.
• Altmış gün sonra ACME istemcinizin artık doğrulamayı almayan bir sunucuya karşı yenileme yaptığını keşfetmek yerine, sertifika yenilemesini gerçekten bir --dry-run ile test edin.
• Uygulamanın otomatik olarak gönderdiği her şey dahil, posta akışını uçtan uca her iki yönde de kontrol edin. Parola sıfırlamaları klasik kayıptır, çünkü bir kullanıcı buna ihtiyaç duyana kadar kimse onları test etmez.
• Yeni sunucunun bir yedeğini alın ve başka bir yerde geri yükleyin. Doğrulanmış bir yedeği olmayan yepyeni bir makine, terk ettiğinizden daha kötü bir konumdur; /guides bu savın tam sürümünü sunar.
• Emin olduğunuzda DNS TTL'sini normal değerine geri döndürün. Onu sonsuza dek 300 saniyede bırakmak, hiçbir kalan faydası olmayan, sorgularda ve gecikmede küçük ama kalıcı bir maliyettir.

Eski sunucuyu hizmetten kaldırmak

Son adım atlanan adımdır ve gizlilik sonucu olan tek adımdır. Eski disk; anahtarlarınızı, veritabanınızı, müşteri verilerinizi ve günlüklerinizi tutar ve hizmeti iptal etmek bunların hiçbirini silmez — birimi, bir sonraki kiracının sağlayıcının silme politikasının geride bıraktığı her şeyi devraldığı bir havuza geri bırakır.

• Herhangi bir şeye dokunmadan önce eski erişim günlüğünün sessizleşmesini bekleyin. Bir ödeme sağlayıcısı hâlâ eski adrese webhook gönderirken iptal etmek, bir taşımanın bir hafta sonra bir olaya dönüşme biçimidir.
• Eski sunucunun tuttuğu her kimlik bilgisini — API anahtarları, veritabanı parolaları, dağıtım anahtarları, geçici taşıma anahtarı — yalnızca silmek yerine döndürün (rotate). Artık kontrolünüzde olmayan bir makinede yaşamış olan her şeyin ele geçirilmiş olduğunu varsayın, çünkü eninde sonunda öyle olur.
• Birimi serbest bırakmadan önce veriyi üzerine yazın. Hassas dizinleri parçalayın (shred), ya da boş alanı büyük, rastgele tek bir dosyayla doldurup silin. Sanallaştırılmış bir diskte kusursuz değildir, ama hiçbir şey yapmamaktan çok daha iyidir.
• Referans olarak isteyebileceğiniz her şeyin — günlükler, yapılandırma, gerçekte ne yapıldığını belgeleyen kabuk (shell) geçmişi — son bir arşivini alın ve bunu, sunucuların ikisinden de ayrı bir yerde şifreli olarak saklayın.
• Hizmeti yalnızca yenisi tam bir faturalandırma döngüsünü ve tam bir yedekleme-ve-geri yükleme testini atlattıktan sonra iptal edin. O örtüşen ay, sürecin en ucuz sigortasıdır.

Kopyalayabileceğiniz bir zaman çizelgesi

Buradaki hiçbir şey tek başına zor değildir. Taşımaların kötü gitmesinin nedeni, adımların TTL'nin henüz dolmadığı, sertifikanın hiç test edilmediği ve geri alma planının hiç yazılmadığı tek bir akşama sıkıştırılmasıdır. Bir haftaya yayıldığında ise her gün yirmi dakikalık bir iştir.

Taşımalar gerçekte nasıl ters gider

Kopyalama yüzünden değil. Hiçbir zaman diskte olmamış şeyler ve iki kez çalışmış şeyler yüzünden.

• İki sunucunun aynı anda yazması — split-brain penceresi ve buradaki, temiz bir çözümü olmayan tek arıza. Bu, araçla değil, sıralamayla önlenir: önce eskiyi durdurun, sonra yeniyi başlatın.
• Zamanlayıcıların her iki makinede de çalışması, ki müşterilerin her şeyden iki tane almasının nedeni de budur. Eskilerini son senkronizasyondan önce devre dışı bırakın, sonra değil.
• Hiç düşürülmemiş bir TTL, beş dakikalık bir geçişi, kimsenin personel ayırmayı planlamadığı gün süren bir kuyruğa dönüştürür.
• Makineler arasında sayısal kimlikler farklı olduğu için dosya sahipliğinin yanlış oturması; böylece uygulama başlar ve ardından kendi yükleme dizinine bile yazamaz.
• Değişiklikten sonra halledilecekti denen bir sertifikanın, ziyaretçilere devam etmenin hiçbir yolunu bırakmayan bir HSTS başlığıyla karşılaşması.
• Kontrolünüzde olmayan bir yerde sabit kodlanmış bir adres — bir ortak entegrasyonu, bir güvenlik duvarı kuralı, var olduğunu unuttuğunuz bir alt alan adı için bir DNS kaydı.
• Eski sunucuyu taşımanın yapıldığı gün iptal etmek; bu da istatistiklerin ona en çok ihtiyaç duyma ihtimalinizin en yüksek olduğunu söylediği tam anda geri alma yolunu ortadan kaldırır.