Kesintisiz VPS Taşıma Rehberi: Geçiş Anı, DNS ve Geri Alma Planı

Kopyalama Kolay Kısımdır — Kesintiye Asıl Neden Olan Şey

Birine taşımasının ne kadar süreceğini sorun, size aktarım süresini tahmin edecektir. Gigabit bir bağlantı üzerinden iki yüz gigabayt, kabaca kırk dakika, biraz da pay bırakmak için bir saat daha ekleyin. Bu sayı genellikle doğrudur ama neredeyse hiçbir zaman önemli olan sayı değildir, çünkü aktarım eski sunucu isteklere yanıt vermeye devam ederken gerçekleşir. Kimse kopyalama sırasında çevrimdışı kalmaz. Çevrimdışı kaldıkları an, yeni makinenin doğru olduğu an ile internetin buna hak verdiği an arasındaki aralıktır ve bu aralığın uzunluğunu sizin kontrol etmediğiniz önbellekler belirler.

Gerçek taşıma kesintilerinin çoğu dört başarısızlık türünden kaynaklanır ve hiçbiri bant genişliğiyle ilgili değildir. Değiştirdiğinizde yaşam süresi hâlâ bir gün olan bir DNS kaydı; bu yüzden dünyanın önemli bir kısmı, çoktan kapattığınız bir makineye bağlanmaya devam eder. Dökümünü aldıktan sonra yazma işlemi kabul eden bir veritabanı; bu yüzden yeni sunucu hayata sessizce bayatlamış bir kopyayla başlar ve hangi yirmi dakikanın eksik olduğunu bir müşteri şikâyetinden öğrenirsiniz. Yalnızca eski diskte var olan bir TLS sertifikası ve onun ACME hesap anahtarı; bu yüzden yeni sunucu her tarayıcıya bir ad uyuşmazlığı sunar. Ve IP adresine göre izin listesine eklenmiş giden bir entegrasyon — bir ödeme işlemcisi, bir banka SFTP teslim noktası, bir ortak API'si, üçüncü bir sağlayıcıdaki bir veritabanı — bu da değişiklikten mümkün olan en uzak ve sessiz noktada başarısız olur.

Herkesin kullandığı ifade konusunda dobra olmakta fayda var. "Sıfır kesintili taşıma" neredeyse her zaman hiçbir insanın fark etmediği birkaç saniyelik reddedilen bağlantı anlamına gelir ve hedeflenmesi gereken de tam olarak budur. Gerçek anlamda sıfır kesinti, iki makinenin aynı anda doğru şekilde hizmet vermesini gerektirir; bu da iki makine olmaya tahammül eden bir uygulama gerektirir: yerel oturum durumu olmayan, yalnızca bir tarafta bulunan yerel bir yükleme dizini olmayan ve ya çoğaltma yapan ya da tamamen başka bir yerde yaşayan bir veritabanına sahip bir uygulama. Çoğu kendi barındırılan yığın bu çıtayı tutturamaz ve dürüst plan, hiç başlatmayı düşünmediğiniz bir mimari projesi yerine kısa, kontrollü, prova edilmiş bir donma penceresidir.

Yani iyi bir taşımanın şekli zekice bir şey değildir. Yeni makineyi erkenden kurun ve eski makine yükü taşırken bunun çalıştığını kanıtlayın. Geri dönüşü olmayan kısmı birkaç dakikalık betikleştirilmiş komuta indirin. Bir seferde tek bir şeyi değiştirin. Ve geri dönebilme yeteneğinizi, bunun için ödemeyi bırakacağınız bir tarihle birlikte koruyun.

Envanter: Sunucunun Deponuzda Olmayan Parçaları

Dağıtım deponuz uygulamayı tanımlar. Makineyi tanımlamaz. İlk apt install ile bugün arasındaki bir noktada, bir sunucu hiçbir sürüm kontrolünün hiç görmediği bir katman biriktirir: tek bir sorunu çözmek için elle kurulmuş paketler, birinin aceleyle yazdığı bir systemd birimi, bir servis hesabı altında çalışan bir cron işi, güvenlik duvarı kuralları, sysctl ayarları, bir yerel ayar (locale), bir saat dilimi, bir takas (swap) dosyası, TLS sertifikaları, SSH host anahtarları, veritabanı rolleri ve yetkileri, ve tam olarak kullanıcılar oraya koyduğu için depoda bulunmayan bir medya dizini. Taşımak, o katmanı bilinçli olarak yeniden üretmek demektir ve bunu bilinçli olarak yapmanın tek yolu önce onu yazıya dökmektir.

Beş komut bunun çoğunu yakalar. Debian ve Ubuntu'da dpkg --get-selections, Rocky ve Alma'da ise dnf repoquery --userinstalled size paket kümesini verir. systemctl list-unit-files --state=enabled size önyüklemede başlayacak şekilde yapılandırılmış her şeyi verir; bu, "şu anda ne çalışıyor"dan daha iyi bir sorudur, çünkü şu anda çökmüş olan şeyi de kapsar. crontab -l -u komutunu /etc/passwd içindeki her hesap için çalıştırmak, artı /etc/cron.d içeriği ve her .timer birimi, size zamanlanmış işleri verir. nft list ruleset veya ufw status numbered size güvenlik duvarını verir. Ve ss -tulpn size gerçekte neyin dinlediğini verir; var olduğunu unuttuğunuz servisi böyle keşfedersiniz. Beşini de dosyalara yazın ve makineden dışarı kopyalayın, makinenin üzerine değil.

Sonra kimsenin yazmadığı ve haftalar sonra ısıran envanter var: şu anki IP adresinize güvenen, her yerdeki her şey. IP izin listesi kullanan ödeme ağ geçitleri. Erişim kuralları eski adresi belirten, başka bir sağlayıcıdaki yönetilen bir veritabanı. Ağa göre kimlik doğrulayan bir SMTP aktarıcısı. Bir izleme servisi, yalnızca bilinen adreslere gönderim yapan bir webhook gönderici, bir meslektaşınızın güvenlik duvarı. Kendi yapılandırmanızda ve belgelerinizde eski adresi arayın (grep), ardından ödeme yaptığınız her üçüncü taraf servisin kontrol panelini kontrol edin. Bunlar geçişten sonra, eş zamansız olarak, entegrasyonun bir sonraki çalıştığı anda bozulur — bu yüzden çoğunlukla "aynı anda başka bir şey daha ters gitti" diye teşhis edilirler.

Son olarak, DNS bölgesinin kendisini de kaydedin. Onu dışa aktarın ya da en azından her kayıt türünü, değerini ve TTL'sini not edin, çünkü bir taşıma tam olarak birinin iki yıldır yanlış olan bir kaydı fark edip bunu her şeyin ortasında iyi niyetle düzelttiği andır.

Önce DNS TTL'sini Düşürün — Ve Neden Günler Önceden Yapılması Gerektiğini Anlayın

Özyinelemeli bir çözümleyici, kendisine verilen yaşam süresi (TTL) boyunca bir yanıtı önbelleğe alır ve bu süre dolmadan tekrar sormak zorunda değildir. Bunun neredeyse herkesi ilk seferde şaşırtan bir sonucu vardır: bir kaydın TTL'sini 86400'den 300'e düşürmek, on dakika önce eski yanıtı önbelleğe almış bir çözümleyici için hiçbir şey ifade etmez. O çözümleyici, gün uzunluğundaki yanıtı yirmi üç saat elli dakika daha tutar ve ancak ondan sonra yeni beş dakikalık TTL'nizi öğrenir. Bu yüzden düşük TTL, herhangi bir şeyi taşımayı planlamadan en az bir tam eski TTL süresi önce yayımlanmış olmalıdır. Kayıtlarınız bir günlük bir TTL üzerindeyse, taşımanın ilk adımı geçişten iki gün önce gerçekleşir ve bu tek satırlık bir değişikliktir.

Bunu yalnızca aklınızdaki kayıt için değil, makineyi işaret eden her kayıt için yapın. A kaydı ve AAAA kaydı — eski sunucuyu işaret etmeye devam eden bir IPv6 adresi güzelce kafa karıştırıcı bir hatadır, çünkü çift yığınlı istemciler sessizce onu tercih eder ve yalnızca bazı kullanıcılarınız etkilenir. MX kayıtları. Önlerindeki her CNAME — bir zinciri takip eden bir istemcinin, zincirdeki her bağlantının TTL'sine tabi olduğunu unutmayın, yani bir günlük bir CNAME'nin arkasındaki beş dakikalık bir A kaydı, fiilen hâlâ bir gündür. Ve aynı zamanda DNS sağlayıcısını da değiştiriyorsanız, bunu aynı hafta içinde yapmayın: ad sunucusu devri ve glue kayıtları, üst bölge tarafından kendi programına göre önbelleğe alınır ve iki değişikliği birleştirmek, bir şey bozulduğunda hangisinin bozduğunu bilemeyeceğiniz anlamına gelir.

Varsaymayın, doğrulayın. dig +noall +answer example.com A size bir çözümleyicinin şu anda elinde tuttuğu yanıtı ve kalan geri sayımı gösterir; yetkili sunucunuzu doğrudan dig @ns1.example.net example.com A ile sorgulamak ise gerçekte ne yayımladığınızı gösterir. İkisi uyuşmuyorsa önbelleğe bakıyorsunuz demektir ve kaydın yanındaki sayı, tam olarak ne kadar beklemeniz gerektiğidir.

Payını ayırmaya değer iki incelik vardır. Bazı çözümleyiciler sınırlar: ISP ve kurumsal yönlendiricilerin bir kısmı, siz ne yayımlarsanız yayımlayın bir asgari TTL'yi zorunlu kılar; bu teknik olarak önerilmez ama tamamen gerçektir. Ve RFC 8767 kapsamında bir çözümleyici, yetkili sunucularınıza ulaşamadığında bilerek bayat bir yanıt sunabilir — dayanıklılık için mükemmel bir davranış, bir değişikliğin yayılmasını istediğiniz gün ise can sıkıcı. İkisi birlikte, trafiğin büyük kısmı taşındıktan sonra saatlerle, bazen bir günle ölçülen uzun bir kuyruk için pay bırakın. Eski makine doğru şekilde yanıt vermeye devam ettiği sürece bu kuyruk bir sorun değildir; zaten açık kalmasının tek nedeni budur. RFC 2181, uygulamalar birbiriyle çelişince TTL'lerin nasıl davranması gerektiğine dair referanstır.

Eski Makine Hâlâ Hizmet Verirken Yeni Kutuda Prova Yapın

Bu sürecin tamamındaki en değerli tek alışkanlık, yeni makinenin önemli olmasından günler önce var olması ve çalışmasıdır. Pratikte bir VPS, saatlik kiralanan bir kaynaktır: bizim planlarımızda bir sunucu, ödeme onaylandıktan yaklaşık altmış saniye sonra canlıya geçer, kurulum ücreti ve sözleşme yoktur; bu yüzden $8.50'lik bir kademede üç günlük bir prova size yaklaşık bir dolara mal olur. Bu, taşımanızdaki her bilinmeyeni saat işlemeye başlamadan önce bir bilinene çevirmenin dikkat çekici derecede ucuz bir yoludur.

Onu IP ile değil, ana bilgisayar adıyla (hostname) test edin. Yeni sunucunun adresine gitmek size varsayılan sanal sunucuyu, SNI eşleşmesi olmayan bir durumu, bir sertifika uyarısını ve üretimi hiç andırmayabilecek bir yönlendirme kümesini verir — ve bir şeyin çalışmadığı hâlde çalıştığına sizi seve seve ikna eder. Doğru araç bir çözümleyici geçersiz kılmasıdır. curl --resolve tek bir komut için bir ana bilgisayar adını tek bir adrese sabitler; böylece curl --resolve example.com:443:203.0.113.10 https://example.com/, dünyanın geri kalanı hâlâ eski sunucuya ulaşırken yeni makineye karşı gerçek adı, gerçek TLS el sıkışmasını ve gerçek sanal sunucuyu çalıştırır. Etkileşimli test için, iş istasyonunuzun hosts dosyasındaki tek bir satır bir tarayıcı için aynı işi görür.

Provanın güvenilir biçimde yakaladığı şey, önceki bölümdeki belgelenmemiş birikmiş katmandır. Son yeniden başlatmadan önce beri çalışan ama aslında etkin olmayan bir arka plan servisi. Hataları bildirmek için yerel bir posta aktarımına bağımlı bir cron işi. Kopyayı sayı olarak atlatan ama farklı bir /etc/passwd'a sahip bir makinede farklı bir anlama gelen dosya sahipliği. Bir yapılandırma dosyasındaki sabit kodlanmış bir adres. Farklı bir varsayılana sahip bir sürümde tek bir karakter kümesiyle oluşturulmuş bir veritabanı. Kullandığınız bir şeyi kullanımdan kaldıran bir Python veya PHP alt sürümü. Bunların her biri, provada düzeltmek için on dakikaya, geçiş sırasında teşhis etmek içinse bir saate mal olur.

Bir test diğerlerinin hepsinden daha değerlidir: yeni makineyi iki kez kurun. Eski sunucuya hiç bakmadan, yalnızca envanterinizi ve yedeğinizi kullanarak onu sıfırdan yeniden kurun. İkinci seferde doğru şekilde ayağa kalkarsa, envanteriniz gerçektir ve eylem planınız uygulanabilirdir. Kalkmazsa, boşluğu bulmanın hiçbir şeye mal olmadığı bir durumda o boşluğu bulmuş olursunuz. Doğru olduğunda bir anlık görüntü alın — her planda yedi gün saklama süreli saatlik anlık görüntüler dahildir ve bir geri yükleme yaklaşık otuz saniye sürer — böylece yeni kutu üzerindeki sonraki her deney de geri alınabilir olur.

İki Kez rsync Çalıştırın: Çalışırken Uzun Bir Geçiş, Pencerede Kısa Bir Geçiş

Bakım penceresini kısa tutan şey, iki geçişli örüntüdür. İlk geçiş, servis tamamen canlıyken çalışır ve gerektiği kadar sürebilir — saatler, gece boyu, bir hafta sonu boyunca. İkinci geçiş, dondurma sırasında çalışır ve yalnızca ilkinden bu yana değişenleri aktarır; bu da normal bir iş yükünde verinin küçük bir kısmı ve öngörülebilir sayıda dakika demektir. Uzun, gözetimsiz bir kopyalamayı kısa, gözetimli bir kopyalamayla takas ediyorsunuz ve bu takas neredeyse her zaman buna değer.

Bayraklar, insanların beklediğinden daha önemlidir. rsync -aHAX --numeric-ids taban çizgisidir: arşiv kipi için -a, sabit bağları (hardlink) korumak için -H — bu, Maildir depoları ve tekilleştirilmiş yedekleme ağaçları için son derece önemlidir; onları düşürmek disk kullanımınızı katlayabilir — POSIX ACL'leri için -A, SELinux etiketleri ve dosya yetenekleri gibi genişletilmiş öznitelikler için -X, ve bir kullanıcı kimliğinin kaynağın kullanıcı veritabanı üzerinden çözümlenip hedefte farklı bir veritabanı üzerinden yeniden çözümlenmesi yerine bir sayı olarak kopyalanması için --numeric-ids. Tek ve makul bir ilerleme satırı için --info=progress2 ve kesintiye uğrayan bir aktarımın yeniden başlamak yerine devam etmesi için --partial ekleyin. Bağlantı gerçekten yavaş olmadıkça -z'yi kapalı bırakın: zaten sıkıştırılmış medyayı ve şifreli arşivleri sıkıştırmak, darboğazı yalnızca CPU'ya taşır.

--delete'i yalnızca ikinci geçişte kullanın. İlk geçişte, hiçbir faydası olmayan bir kendine zarar verme aracıdır, çünkü hedefte kaldırılması gereken hiçbir şey yoktur. İkinci geçişte ise gereklidir: onsuz, iki geçiş arasında eski sunucuda sildiğiniz bir dosya yenisinde sonsuza dek yaşamaya devam eder; bir taşımanın bilerek kaldırılmış içeriği sunar hale gelmesinin yolu da tam olarak budur.

Kesinlikle yapmamanız gereken şey, tüm kök dosya sistemini rsync ile kopyalamaktır. Bu popüler bir kestirme yoldur ve kimsenin hakkında akıl yürütemeyeceği bir makine üretir. /proc, /sys, /dev, /run ve /tmp hariç tutulsa bile, kerneli ve initramfs'i bir sunucudan gelen, ağ arayüzü adlandırması farklı bir donanımdan türetilmiş, /etc/machine-id'si artık iki canlı makinede birden yinelenen ve tam olarak korumak için para ödediğiniz beş yıllık birikmiş yapılandırma savrulmasına sahip bir sistemle baş başa kalırsınız. Envanterini çıkardığınız veriyi ve yapılandırmayı taşıyın; işletim sistemini bir şablondan sıfırdan kurun. Bu bir saat fazladan sürer, size temiz ve modern bir taban verir ve yeni sunucunun anlamadığınız bir şeyin kopyası değil, anladığınız bir makine olmasını sağlar.

Çıkış koduna güvenmek yerine kopyayı doğrulayın. Her iki geçişten sonra, aynı komutu -n --checksum --itemize-changes ile tekrar çalıştırın: zaman damgaları yerine içeriği karşılaştıran ve her fark için bir satır yazdıran bir prova çalıştırması (dry run). İstediğiniz sonuç sessizliktir ve bu, her iki tarafta da eşleşen bir du -s'tan çok daha güçlü bir kanıttır.

rsync'in Size Yardımcı Olamayacağı Kısım: Veritabanı

Canlı bir veritabanı dizinini dosya düzeyinde kopyalamak size yırtık bir kopya verir: bazı sayfalar yazılmış, bazıları yazılmamıştır ve bunun herhangi bir kısmının tutarlı bir işlem sınırı oluşturduğuna dair hiçbir garanti yoktur. InnoDB bundan gayet iyi kurtulup sorunsuz görünebilir; bu, başarısız olmaktan bile daha kötüdür, çünkü bunu ancak kurtarmanın işe yaramadığı gün öğrenirsiniz. Tam olarak iki dürüst strateji vardır — işlemsel olarak tutarlı bir döküm almak ya da çoğaltma yapmak — ve ikisi arasındaki seçim, ne kadar kesinti satın aldığınıza dair bir seçimdir.

MySQL ve MariaDB'de döküm yolu için mysqldump --single-transaction --routines --triggers --events, tüm sunucuyu kilitlemeden tutarlı bir anlık görüntü verir; bilinmeye değer iki uyarıyla birlikte: yalnızca işlemsel tablolar için tutarlıdır, yani tek bir eski MyISAM tablosu bu garantiyi sessizce bozar, ve döküm sırasında çalıştırılan herhangi bir DDL ifadesi de onu bozar. PostgreSQL'de pg_dump -Fc her veritabanını ele alır ve pg_dumpall --globals-only insanların unuttuğu yarısını ele alır — roller, parolalar, yetkiler ve tablespace'ler herhangi bir tek veritabanının içinde değil, küme (cluster) düzeyinde yaşar; bu yüzden onlar olmadan yapılan bir geri yükleme, uygulamanın kimlik doğrulayamadığı kusursuz bir veri üretir.

Pencerenizi belirleyen sayı döküm boyutu değildir; döküm artı aktarım artı geri yükleme artı indeks yeniden oluşturmadır ve bunların sonuncusu genellikle en büyüğüdür. Bunu tahmin etmek yerine gerçek veri kümesi üzerinde prova sırasında ölçün. Birkaç gigabayt dakikalar sürer; ciddi indeksleme içeren yüz gigabayt saatler sürebilir ve bu noktada döküm yolu canlı bir servis için artık uygulanabilir olmaktan çıkar, çoğaltma ise bir optimizasyon değil, cevabın kendisi hâline gelir.

Çoğaltma yolu maliyeti tersine çevirir: işi önceden yaparsınız ve geçiş önemsiz hâle gelir. Yeni sunucuda günler öncesinden bir replika kurun — MySQL ve MariaDB için GTID tabanlı çoğaltma, PostgreSQL için pg_basebackup ve akan bir bekleme sunucusu (streaming standby), ya da aynı zamanda büyük bir sürüm geçişi de yapıyorsanız mantıksal çoğaltma (logical replication). Onun yetişmesine ve yetişmiş kalmasına izin verin. Geçiş o zaman şu olur: birincil üzerinde yazmaları durdurun, replikanın sıfır gecikme bildirmesini bekleyin, onu yükseltin (promote), uygulamayı ona yönlendirin. Bu saniyeler sürer ve dürüstçe "neredeyse sıfır kesinti" ifadesini hak eden tek yaklaşım budur.

Veritabanında olmayan durumu unutmayın. Redis, Valkey ve Memcached oturumları, hız sınırlama sayaçlarını ve kuyrukları tutar; Elasticsearch, OpenSearch veya Meilisearch'teki bir arama indeksi ise verinizin türetilmiş bir kopyasını tutar. Her biri için, onu taşımak mı yoksa yeniden mi oluşturmak istediğinize açıkça karar verin. Herkesi oturumdan atmaya razıysanız hariç, oturumları tutan bir Redis örneğini bir BGSAVE ve ortaya çıkan dosyanın bir kopyasıyla taşımaya değer. Bir arama indeksini yeni sunucuda yeniden indekslemek, neredeyse her zaman aktarmaktan daha hızlıdır — ama yeniden indeksleme zaman alır, bu yüzden onu dondurma sırasında değil, prova sırasında başlatın.

TLS Sertifikaları, SSH Host Anahtarları ve Sadece Yeniden Veremeyeceğiniz Kimlikler

Sertifika verilmesi, tam olarak yanlış anda tavuk-yumurta problemi yaşar. HTTP-01 sınaması, bir ad üzerinden bir dosya çekerek o adın kontrolünü kanıtlar; bu da adın doğrulanan makineye zaten çözümleniyor olmasını gerektirir — geçişten önce ise böyle değildir. Bunun üç çıkış yolu vardır ve bilinçli olarak birini seçmelisiniz. Sertifika dizinini karşıya kopyalayın; bu hemen işe yarar ve anahtar sizin olduğu için tamamen meşrudur. Bunun yerine, bir TXT kaydı yayımlayarak doğrulama yapan ve bu yüzden henüz hiçbir şeyin işaret etmediği bir makinede de çalışan DNS-01 sınamasını kullanın; bu ayrıca joker (wildcard) bir sertifika için zaten tek seçenektir. Ya da DNS geçişinden sonra, yeni sunucunun kendi sertifikasını istediği kısa bir pencereyi kabul edin; bu kişisel bir site için sorun değildir ama kullanıcıları olan hiçbir şey için uygun değildir.

Kopyalayacaksanız, tamamını kopyalayın. Sertifikalar ve özel anahtarlar bariz kısımdır; geride bırakılan kısım ise ACME hesap anahtarıdır ve o olmadan yeni sunucudaki istemci ilk yenilemede yepyeni bir hesap kaydeder. Her şey çalışıyor gibi görünür ve siz hesabın geçmişini ve hesap kapsamındaki her durumu sessizce kaybetmiş olursunuz. Sahipliği ve izinleri de koruyun — özel anahtarlar 600'de, arşiv dizini 700'de olmalı — çünkü bir anahtarın izinlerini genişleten bir kopya, endişelendiğiniz taşımadan daha kötü bir sonuçtur.

Tekrar tekrar yeniden vermeyi planlayıp ne olacağını görmeyin. Let's Encrypt hız sınırları, aynı ana bilgisayar adı kümesi için haftada tekrarlanan sertifikaları sınırlar ve iki başarısız prova artı bir gerçek verme işlemi, beklemeyi göze alamayacağınız o tek günde tavana ulaşmanın şaşırtıcı derecede kolay bir yoludur. Provaları staging ortamına yönlendirin; üretim uç noktasını gerçek işlem için saklayın.

SSH host anahtarları burada devrede olan diğer kimliktir ve doğru cevap gerçekten neden taşındığınıza bağlıdır. /etc/ssh/ssh_host_*'ı kopyalamak taşımayı görünmez kılar: her istemcinin known_hosts'u hâlâ eşleşir ve hiçbir otomasyon bir parmak izi uyarısıyla durmaz. Bu kullanışlıdır ve güvendiğiniz sağlayıcılar arasında rutin bir taşıma için doğru tercihtir. Ayrılma nedeniniz artık eski sunucuya veya eski sağlayıcıya güvenmemenizse bu yanlış tercihtir — o diske erişimi olan herkes host özel anahtarınıza da sahip olmuştur ve onu yeni sunucuya taşımak sorunu da beraberinde taşır. Bu durumda yeni anahtarlar üretin, yeni parmak izini sunucu olmayan bir kanal üzerinden yayımlayın ve istemcilerin eski girdiye karşı ssh-keygen -R çalıştırmasını sağlayın. Anahtarların nerede yaşadığı ve nasıl seçildiği için OpenSSH sshd kılavuzuna bakın.

Her iki durumda da mutlak olan bir kural vardır: aynı host anahtarıyla ve aynı ana bilgisayar adının ikisine de çözümlendiği iki makineyi asla aynı anda çalıştırmayın. Bu, bir istemcinin hangi sunucuya ulaştığını ayırt edemediği bir yapılandırmadır; host anahtarlarının var olma amacı da tam olarak bunu önlemektir. Örtüşme penceresi boyunca, ya eski sunucu kendi kimliğini korur ve yenisi kendi kimliğine sahip olur, ya da yeni sunucu anahtarını devraldığı anda eski sunucunun adı hizmetten kaldırılır.

Geçiş Anı: Yazıya Dökülmesi Gereken On Dakika

Şimdiye kadarki her şey geri alınabilir ve acelesizdi. Geçiş anı ikisi de değildir; bunu önceden yazıya dökmenin tüm gerekçesi de budur: zaman baskısı altında doğaçlama, beş dakikalık bir pencereyi iki saatlik bir olaya dönüştüren şeydir. Eylem planı, her birinin yanında beklenen çıktısıyla birlikte, sırayla verilmiş harfiyen komutlardan oluşmalıdır; böylece onu yürütmek düşünmeyi değil, okumayı gerektirir.

İşe yarayan sıra şudur. Birinci, eski sunucuda yazmaları durdurun — bir bakım sayfası, salt okunur bir bayrak, ya da web sunucusu hâlâ bir bekletme sayfasıyla yanıt verirken uygulamayı basitçe durdurmak. İkinci, --delete ile son rsync geçişini çalıştırın. Üçüncü, veritabanı adımını tamamlayın: ya ölçtüğünüz döküm-aktarım-geri yükleme, ya da birincil üzerinde yazmaları durdurup sıfır çoğaltma gecikmesini doğrulayarak replikayı yükseltmek. Dördüncü, yeni sunucudaki servisleri başlatın ve yerleşmeleri için onlara biraz zaman tanıyın — bağlantı havuzları, kuyruk işçileri ve sertifika yüklemesi soğuk bir başlangıçta hatırladığınızdan daha uzun sürer. Beşinci, doğrulayın. Altıncı — ve yalnızca doğrulama başarılı olduktan sonra — DNS kayıtlarını değiştirin. Yedinci, eski sunucuyu çalışır durumda bırakın.

Doğrulamanın bir anlamı olmalıdır. Ana sayfayı çekmek yalnızca web sunucusunun ayakta olduğunu kanıtlar, başka hiçbir şeyi değil. Veritabanına dokunan ve üzerinde iddiada bulunabileceğiniz bir şey döndüren bir yol üzerinde, gerçek ana bilgisayar adına karşı curl --resolve kullanın — veritabanı bağlantısını, önbellek bağlantısını ve boş disk alanını kontrol eden bir sağlık uç noktası, yalnızca bu neden için bile yazmaya değer. Sonra yeni sunucunun erişim günlüğünü okuyun ve isteğinizin orada olduğunu doğrulayın. Bu son adım kılı kırk yarmak gibi görünür ama tam olarak çözümleyici geçersiz kılmanızın etkili olmadığı ve sizin aslında eski sunucuyu özenle doğrulamış olduğunuz durumu yakalayan adımdır.

DNS geçişinden sonra, her iki erişim günlüğünü de yan yana izleyin. Yeni sunucudaki trafik yükselir; eski sunucudaki trafik önbellekler süresi dolduğunda söner, ve bu sönme eğrisi kuyruğun gerçekte ne kadar uzun olduğunun tek dürüst ölçümüdür. Eski sunucunun günlüğü sıfıra yakın düzleştiğinde, taşıma tamamlanmış demektir. O ana kadar, eski makine ona hâlâ ulaşan kullanıcılar için doğru davranmaya devam etmelidir — bir coşku anında kapatılmak yerine güçlü ve salt okunur kalmasının nedeni de budur. Uygulama salt okunur hâle getirilemiyorsa, eski sunucunun birkaç saat boyunca bayat veri sunması, genellikle eski sunucunun bağlantı reddedildi hatası vermesinden daha küçük bir zarardır; ama bu, o anda değil önceden verilmesi gereken bir karardır.

Tek bir şeyi değiştirin. Hem işletim sisteminin ana sürümünü hem de sunucuyu değil. Hem DNS sağlayıcısını hem de kayıtları değil. Hem PHP sürümünü hem de makineyi değil. Her eşzamanlı değişiklik, sabahın üçünde bir şeyler ters gittiğinde test etmeniz gereken hipotezleri katlar; ve dahil etmeye can attığınız o yükseltme, gelecek hafta hâlâ orada olacaktır — artık geri dönebileceğiniz bir makine üzerinde.

Posta, rDNS ve Sizinle Birlikte Taşınmayan İtibar

Sunucu posta gönderiyorsa, taşımanın taşımayla hiçbir ilgisi olmayan bir ikinci yarısı vardır. Bir IP adresi bir gönderim itibarı taşır, bu itibar haftalar içinde inşa edilir ve sizinle birlikte gelmez. Teknik açıdan kusursuz bir taşımanın bir haftalık kullanıcı şikâyetine dönüşmesinin en yaygın tek yolu budur ve tüm önlemler geçişten sonra değil önce başlamalıdır.

İlk bozulan kayıt SPF'dir. Eski adresi belirten bir ip4: mekanizması içeren bir politika, yeni adresten göndermeye başladığınız an başarısız olmaya başlar; ve RFC 7208 politikaları DNS kayıtları olduğundan, planlamanız gereken kendi TTL'leri vardır. Yeni adresi geçişten önce SPF'ye ekleyin, örtüşme sırasında ikisini de listede tutun ve hizmetten kaldırırken eskisini kaldırın. Genel yarı zaten yayımlanmış olduğundan, özel anahtarı yapılandırmanın geri kalanıyla birlikte kopyaladığınız sürece DKIM sorunsuzca taşınır. DMARC'ın değişmesi gerekmez, ama raporlama adresinin, birazdan yok edilecek bir makinede hâlâ var olduğunu doğrulamaya değer.

Gönderim yapan bir sunucu için ters DNS isteğe bağlı değildir. Yeni adresteki PTR kaydı var olmalı ve sunucunun HELO veya EHLO'sunda duyurduğu adla eşleşmelidir, yoksa alıcıların büyük bir kısmı yalnızca bu yüzden reddeder. Bizim planlarımızda PTR panelden düzenlenebilir, yani bu bir destek talebi değil bir onay kutusudur — provada ayarlayın, çözümlendiğini doğrulayın ve ileri kaydın geri eşleştiğini teyit edin. Ardından, herhangi bir şey göndermeden önce yeni adresi başlıca kara listelere karşı kontrol edin: geri dönüştürülmüş adresler bazen zaten listelenmiş olarak gelir ve bunu kendi test mesajınızdan öğrenmek hiçbir şeye mal olmazken bir müşteriden öğrenmek çok pahalıya mal olur. En çok önem taşıyan Spamhaus'tur.

Alma tarafı için, her iki sunucuyu da erişilebilir tutun. Yeni sunucuyu öncelik-10 MX olarak ekleyin ve eskisini silmek yerine bir hafta boyunca öncelik 20'de bırakın: göndericiler yeniden dener, bazıları MX kaydınızı önbelleğe almıştır ve eski sunucuda sessizce kabul eden bir posta sunucusu, bir geri dönüşten (bounce) çok daha iyidir. Ardından, eski makineyi yok etmeden önce kuyruğunu boşaltın — teslimat girişimini zorlamak için postqueue -f ve sonucun boş olduğunu doğrulamak için mailq. Yok etmek üzere olduğunuz bir sunucudaki kuyrukta bekleyen mesajlar gecikmiş değildir. Onlar gitmiştir. Kendi barındırdığınız posta sunucusu rehberi, teslim edilebilirlik tarafını tam olarak ele alır.

Eski Sağlayıcı Makineyi Zaten Kapattığında

Her taşıma planlı olmaz. Bir kötüye kullanım şikâyetinden sonra askıya alma, süresi dolmuş bir kart, kimsenin açıklamayacağı bir nedenle kilitlenmiş bir hesap — ortak nokta, artık giriş yapamadığınız bir makineden taşıma yapıyor olmanız ve yukarıdaki rahat işlem sırasının artık geçerli olmamasıdır. Genellikle hâlâ neyin mümkün olduğunu önceden bilmeye değer, çünkü mümkün olduğu pencere çoğunlukla kısadır.

Bir sunucu askıya alınmış ama henüz silinmemişken, azalan yararlılık sırasına göre sıklıkla üç yol açık kalır. Kontrol paneli hâlâ bir anlık görüntü veya yedek indirmesi sunuyor olabilir; bu, tüm sorunu tek adımda çözer. Bir kurtarma modu, diskiniz takılı olarak hâlâ canlı bir imaj önyükleyebilir ve bu, dosya sistemini bağlayıp önemli olanı ağ üzerinden dışarı kopyalamanızı sağlar. Ve acil durum konsolu, ağ devre dışı bırakılmış olsa bile hâlâ bağlanabilir; bu, yapılandırma dosyalarını okumaya, bir anahtarı kurtarmaya veya neyin kurulu olduğunu not almaya yeter — ama bir veritabanı için bir yol değildir, bu yüzden buna göre plan yapmayın. Bunları bu sırayla ve hemen deneyin: askıya almadan sonraki saklama bir hak değil bir politikadır ve sıklıkla günlerle ölçülür.

Hiçbir destek talebinin çözemeyeceği bir sınır vardır ve bunu açıkça belirtmeye değer, çünkü bu, bu sitenin sattığı modelin doğrudan bir sonucudur. Hiçbir zaman kimlik toplamamış bir sunucuda — bu site de dahil — hesap kimlik bilgilerine sahip olmak dışında hesap sahibi olduğunuzu kanıtlamanın bir yolu yoktur. KYC'siz barındırmanın tüm meselesi budur ve aynı zamanda faturasıdır: kimse bir pasaport fotoğrafının gücüyle erişiminizi geri yükleyemez, çünkü hiçbir zaman hiçbir şeye bir pasaport eklenmemiştir. KYC'siz barındırma rehberi bu ödünleşimi tam olarak ele alır; operasyonel sonuç ise basitçe kurtarma planınızın başka birinin iyi niyeti üzerinden ilerleyemeyeceğidir.

Acil durum sırası, örtüşmesi kaldırılmış planlı sıradır. Yeni sunucuyu makine dışındaki yedeğinizden ayağa kaldırın. Onu ana bilgisayar adıyla düzgünce doğrulayın, çünkü doğrulamayı atlama isteği tam olarak zaten çevrimdışıyken en güçlüdür. Ardından DNS'i hemen taşıyın — TTL disiplini hâlâ geçerlidir, tek fark artık önbellek kuyruğunu örtüşme olarak harcamak yerine kesinti olarak ödüyor olmanızdır; bu da TTL'leri bir taşıma adımı olarak değil kalıcı bir politika olarak mütevazı tutmanın en net gerekçesidir. Bir süre bozulmuş posta hizmetini bekleyin ve insanları sonradan açıklamak yerine erkenden uyarın.

Bu dersin genelleşmesi, bu tek kötü günün ötesine geçer. Sunucunun üzerinde yaşayan bir yedek, yedek değildir; kaybetmek üzere olduğunuz şeyin ikinci bir kopyasıdır. Önemli olan özellik, kopyanın başka bir yerde olması, ağdan çıkmadan önce şifrelenmesi, ele geçirilmiş veya askıya alınmış bir sunucunun kendi geçmişini silemeyeceği şekilde yalnızca-eklemeli (append-only) olması ve — herkesin atladığı kısım — geri yüklemenin işe yaradığını bilmek için gerçekten bir kez, harcanabilir bir sunucuya geri yüklenmiş olmasıdır. Sertleştirme kontrol listesi, bunu yeni bir makinede kurmayı ele alır; bu bölümü zaten çok geç olduğu için okuyorsanız, bunu bugün, her şeyden önce, taşındığınız makinede kurun.

Geri Alma: Tetikleyiciyi Tanımlayın ve Ona Bir Son Kullanma Tarihi Verin

Neredeyse herkes bir geri alma planı olduğunu söyler ve neredeyse kimse onu neyin tetikleyeceğini yazmamıştır. Bir tetikleyici olmadan, karar en kötü anda en yorgun olan kişi tarafından verilir ve olağan sonuç, kimsenin geri almamasıdır; çünkü mevcut sorunun düzeltilmesine hep beş dakika kalmış gibi hissedilir. Önceden karar verin: bir süre boyunca bir eşiğin üzerindeki hata oranı, belirli bir işlevin bozulması, ya da basitçe hata ayıklamayı bırakıp geri döneceğiniz bir duvar saati zamanı.

Geri almanın gerçekte ne anlama geldiğini belirleyen kısıt, yazma işlemleridir. Yeni sunucu ilk yazmasını kabul ettiği andan itibaren, geri dönmek ya o yazmaları atmak ya da onları eski makineye yeniden oynatmak anlamına gelir. Yani aslında iki farklı şey arasında seçim yapıyorsunuz. İlk yazmadan önce yapılan bir geri alma bir DNS değişikliğidir ve dakikalar sürer. Bir günlük üretim trafiğinden sonra yapılan bir geri alma ise, tüm aynı adımlarla ters yönde bir taşımadır ve bu rehberin anlattığı kadar sürer. Herhangi bir anda hangisine sahip olduğunuzu bilin ve ikinci türün, eski makinenin kutusunu başka bir amaca ayırmak yerine veritabanını bir geri yüklemeyi kabul edebilir durumda tuttuysanız çok daha kolay olduğunu unutmayın.

Eski sunucuyu yaklaşık bir hafta boyunca tutun: güçlü, salt okunur, DNS TTL'i hâlâ düşük, izleme hâlâ ona yönlendirilmiş. En küçük planda bu sigorta yaklaşık iki dolara mal olur ki bu, kararda yer alması gereken bir sayı değildir. Yer alması gereken şey, bir haftanın; haftalık cron işlerinin, aylığa yakın raporların ve yalnızca cumaları tetiklenen entegrasyonun yeni sunucuda en az bir kez çalışmış olması için yeterli olmasıdır — bunlar, iki günlük bir pencerenin tamamen kaçıracağı başarısızlıklardır.

Ardından bilinçli olarak hizmetten kaldırın. Eski sunucunun erişim günlüğünün bir gündür düz kaldığını doğrulayın. Onun son bir yedeğini alın ve bunu ihtiyacınız olduğunu düşündüğünüzden daha uzun süre saklayın. Elinde tuttuğu her şeyi iptal edin: API anahtarları, deploy anahtarları, veritabanı kullanıcıları, başkalarının IP izin listelerindeki girdileri, izleme kontrolleri, SPF girdisi, MX kaydı. Sunucuyu yok edin. Ve son olarak DNS TTL'lerini makul bir değere geri döndürün — kalıcı 300 saniyelik bir TTL, çözümleyicilerin sitenin geri kalan ömrü boyunca saatte yirmi kez yeniden doğrulama yapması anlamına gelir; bu da taşıma bittikten sonra size hiçbir şey kazandırmaz ve her soğuk sorguda biraz gecikmeye mal olur. Bir saat makul bir kalıcı değerdir; hızla değişmesini hiç beklemediğiniz kayıtlar için bir gün de uygundur.

Taşıma: Çalıştırma Sırasıyla

Bir hafta öncesinden, eski makinenin envanterini çıkarın ve eylem planını yazın: paketler, etkin birimler, crontab'lar, güvenlik duvarı, dinleyen soketler, veritabanı rolleri ve eski adresi izin listesine eklemiş her üçüncü taraf. Üç gün öncesinden, yeni VPS'i hazırlayın, üzerine geri yükleyin ve bir çözümleyici geçersiz kılmasıyla ana bilgisayar adı üzerinden her şeyi prova edin — sonra envanterin gerçek olduğunu kanıtlamak için onu yalnızca envanterden bir kez daha yeniden kurun. İki gün öncesinden, düşük değere ihtiyaç duymadan önce bir tam eski TTL'nin geçmesi için A, AAAA ve MX TTL'lerini 300'e düşürün.

Bir gün öncesinden, üretim devam ederken -aHAX --numeric-ids ile ilk rsync geçişini çalıştırın ve veritabanı çoğaltmasını başlatın ya da döküm penceresini gerçek veri kümesi üzerinde ölçün. Sertifikaları da aynı geçişte halledin — ACME hesap anahtarı dahil sertifika dizinini kopyalayın ya da DNS-01'e geçin — ve ondan herhangi bir posta gönderilmeden önce yeni adres üzerinde PTR kaydını ve yeni SPF girdisini ayarlayın.

Pencerede: yazmaları dondurun, --delete ile son rsync'i çalıştırın, veritabanını tamamlayın, servisleri başlatın, veritabanına dokunan bir yol üzerinde gerçek ana bilgisayar adına karşı doğrulayın, isteğin yeni sunucunun günlüğüne düştüğünü teyit edin ve ancak o zaman DNS'i çevirin. Eski sunucuyu güçlü ve salt okunur bırakın. Eskisi düzleşene kadar her iki erişim günlüğünü de izleyin.

Bir hafta sonra: haftalık işlerin yeni sunucuda çalıştığını doğrulayın, eskisinin son bir yedeğini alın, anahtarlarını ve izin listesi girdilerini her yerde iptal edin, onu yok edin ve TTL'leri eski hâline yükseltin. Yeni makinenin, terk ettiğinizden sadece daha yeni değil daha iyi olmasını istiyorsanız, sertleştirmenin ilk on beş dakikası doğal bir sonraki adımdır ve bunu henüz kendi belgelenmemiş katmanını biriktirmemiş bir sunucuda yapmak çok daha kolaydır. Nereye yerleşeceğinizi hâlâ seçiyorsanız, yargı bölgesi rehberi İzlanda, Hollanda, Romanya ve İsviçre arasında gerçekte nelerin farklı olduğunu ele alır — ve provaya bugün başlamak için hedef makineyi yaklaşık bir dakika içinde çalışır hâle getirebilirsiniz.