Azure Linux Sanal Makinesini Ölümden Döndürme: SSH, Agent ve İşletim Sistemi Diski Çöktüğünde Bir Üretim Ortamı Kurtarma Hikayesi
Üretim ortamındaki bir sanal makinenin aniden erişilemez hale gelmesi, her DevOps mühendisinin veya sistem yöneticisinin kâbusudur. Peki ya bu erişilemezlik sadece SSH bağlantısının kopmasından ibaret değilse? Ya Azure Linux Agent’ı da çalışmıyorsa ve hatta işletim sistemi diski bile bozulmuşsa? İşte tam da böyle bir senaryoyu, Azure üzerindeki kritik bir Linux sanal makinesini nasıl ölümden döndürdüğümüzü, adım adım, tüm detaylarıyla anlatacağımız gerçek bir savaş hikayesiyle karşınızdayız. Bu makale, sadece teknik bir rehber olmanın ötesinde, kriz anında nasıl sakin kalınacağını, sistematik düşünme ve problem çözme yeteneklerinin önemini de gözler önüne serecektir.
Krizin Başlangıcı: Belirtiler ve İlk Panik
Her şey, bir sabah erken saatlerde monitoring sistemlerimizden gelen bir dizi uyarıyla başladı. Kritik bir üretim sunucusunun yanıt vermediği, üzerindeki uygulamanın erişilemez olduğu bilgisi hızla yayıldı. İlk başta basit bir ağ sorunu veya uygulama donması zannettiğimiz durum, kısa sürede çok daha karmaşık ve ciddi bir felakete dönüştüğünü gösterdi.
Erişilemezlik ve İlk Gözlemler
Sunucuya SSH ile bağlanma denemelerimiz başarısızlıkla sonuçlandı. Bağlantı zaman aşımına uğruyor, herhangi bir yanıt alamıyorduk. Bu durum, sunucunun ağ katmanında bir sorun olabileceği veya SSH servisiyle ilgili ciddi bir problem yaşandığına işaret ediyordu. Ancak daha derine indiğimizde, sorunun çok daha temel bir seviyede olduğunu fark ettik. Sunucunun ping isteğine dahi yanıt vermemesi, ağ arayüzlerinin veya işletim sisteminin tamamen çökmüş olabileceği ihtimalini akıllara getirdi.
Azure Portal’daki Durum ve Hata Mesajları
Azure portalına baktığımızda, sanal makinenin durumunun “Running” (Çalışıyor) olarak görünmesi ilk başta yanıltıcıydı. Ancak VM’in “Overview” (Genel Bakış) sayfasındaki “Agent Status” (Aracı Durumu) bölümünde “Not Ready” (Hazır Değil) veya “Agent Status Unknown” (Aracı Durumu Bilinmiyor) gibi mesajlar belirmeye başlamıştı. Bu, Azure Linux Agent’ının düzgün çalışmadığını, dolayısıyla Azure’ın VM üzerinde herhangi bir yönetimsel işlem (uzantı çalıştırma, parola sıfırlama vb.) yapamayacağı anlamına geliyordu. Daha da endişe verici olan, “Boot Diagnostics” (Önyükleme Tanılaması) ekranında takılı kalmış bir önyükleme mesajı veya hata ekranı görmemizdi. Bu, işletim sisteminin sağlıklı bir şekilde başlatılamadığına dair net bir kanıttı.
Üretim Etkisi ve Aciliyet
Bu sanal makine, şirketimiz için kritik bir uygulamanın ana sunucusuydu. Erişilemez olması, doğrudan müşteri hizmetlerinin aksamasına ve gelir kaybına yol açıyordu. Durumun aciliyeti, tüm ekibi bir araya getirdi ve sorunu en kısa sürede çözmek için yoğun bir çaba içine girmemizi gerektirdi. Baskı yüksekti, ancak panik yapmak yerine sistematik bir yaklaşım sergilemek zorundaydık.
Sorun Tespiti ve Kapsam Belirleme
Kriz anında en önemli adımlardan biri, sorunun tam olarak ne olduğunu ve ne kadar geniş bir alanı etkilediğini anlamaktır. Bu, doğru kurtarma stratejisini belirlemek için hayati öneme sahiptir. Yaptığımız ilk incelemeler, sorunun tahmin ettiğimizden daha katmanlı olduğunu ortaya koydu.
SSH Bağlantı Sorunları
SSH bağlantı sorunları genellikle ilk fark edilen belirtidir. Sunucuya bağlanmaya çalıştığımızda “Connection refused”, “Connection timed out” veya “No route to host” gibi hatalar alıyorduk. Bu, SSH servisiyle ilgili bir problemden (çalışmıyor, yanlış yapılandırılmış), güvenlik duvarı kurallarından veya ağ bağlantı sorunlarından kaynaklanabilir. Ancak ping de çalışmadığı için, sorunun daha derinde olduğu açıktı.
Azure Linux Agent Durumu
Azure Linux Agent, Azure VM’lerinin yönetimi için kritik bir bileşendir. Uzantıların yüklenmesi, parola sıfırlama, veri disklerinin yönetimi gibi birçok işlem bu agent üzerinden yapılır. Portalda “Not Ready” olarak görünmesi, agent’ın ya hiç çalışmadığı ya da işletim sistemiyle iletişim kuramadığı anlamına geliyordu. Bu durum, standart Azure kurtarma araçlarını kullanmamızı engellediği için işleri daha da zorlaştırdı.
İşletim Sistemi Diski Sağlık Kontrolü
Boot Diagnostics ekranındaki takılı kalmış önyükleme mesajları, işletim sistemi diskinin bozulmuş olabileceği şüphesini doğurdu. Disk üzerindeki dosya sistemi hataları, bozuk önyükleme kayıtları veya kritik sistem dosyalarının zarar görmesi, işletim sisteminin başlatılmasını engelleyebilir. Bu, en ciddi sorunlardan biriydi çünkü doğrudan veri bütünlüğünü tehdit ediyordu.
Boot Diagnostics ve Seri Konsol İncelemesi
Azure’ın sunduğu “Boot Diagnostics” ve “Seri Konsol” özellikleri bu aşamada altın değerindeydi. Boot Diagnostics, VM’in önyükleme sürecinin ekran görüntülerini veya seri konsol günlüklerini görmemizi sağlar. Bizim durumumuzda, seri konsol çıktıları, önyükleme sırasında belirli bir aşamada takılı kaldığını ve dosya sistemiyle ilgili hatalar verdiğini gösteriyordu. Bu, işletim sistemi diskinin gerçekten de sorunlu olduğunu doğruladı ve bizi bir sonraki adıma yönlendirdi.
Kurtarma Stratejisi Oluşturma: Adım Adım Yaklaşım
Karşılaştığımız sorunun çok katmanlı olması nedeniyle, tek bir sihirli çözüm beklemek yerine, adım adım ve kontrollü bir kurtarma stratejisi oluşturmak zorundaydık. Önceliğimiz veri bütünlüğünü sağlamak ve ardından işletim sistemini onarmaktı.
Veri Bütünlüğünü Sağlama Önceliği
Herhangi bir kurtarma işlemine başlamadan önce, mevcut durumdaki verilerin zarar görmemesini sağlamak en önemli adımdır. Bu nedenle, ilk olarak sanal makinenin işletim sistemi diskinin anlık görüntüsünü (snapshot) aldık. Bu anlık görüntü, olası bir yanlış adımda geri dönebileceğimiz bir kurtarma noktası oluşturdu. Ayrıca, veri diskleri ayrı olduğu için onların durumunu da kontrol ettik ve sağlıklı olduklarını teyit ettik.
Kurtarma VM’i Oluşturma
İşletim sistemi diski bozuk olduğu ve VM’e doğrudan erişemediğimiz için, ana VM’in diskini bağlayabileceğimiz yeni bir “kurtarma VM’i” oluşturmaya karar verdik. Bu kurtarma VM’i, aynı bölgede ve aynı işletim sistemi ailesinden (örneğin, Ubuntu ise yine Ubuntu) olmalıydı. Bu sayede, bozuk diski bu yeni VM’e ikincil bir disk olarak bağlayıp, üzerindeki dosya sistemini onarabilecek ve gerekli değişiklikleri yapabilecektik.
Adım Adım Kurtarma Planı
Kurtarma planımızı şu şekilde özetledik:
- Orijinal OS diskinin anlık görüntüsünü al.
- Yeni bir kurtarma VM’i oluştur.
- Orijinal OS diskini (veya anlık görüntüden oluşturulan bir kopyasını) kurtarma VM’ine veri diski olarak bağla.
- Kurtarma VM’i üzerinden bozuk diskin dosya sistemini kontrol et ve onar (fsck).
- Kritik sistem dosyalarını (SSH yapılandırması, fstab, GRUB vb.) kontrol et ve düzelt.
- Azure Linux Agent’ı ile ilgili sorunları gider.
- Diski kurtarma VM’inden ayır.
- Orijinal VM’in OS diskini, onardığımız diskle değiştir (veya onardığımız diski orijinal VM’e yeniden bağla).
- Orijinal VM’i başlat ve kontrolleri yap.
İşletim Sistemi Diski Kurtarma Operasyonu
Kurtarma planımızın en kritik aşaması, bozuk işletim sistemi diskini onarmaktı. Bu aşama, dikkatli ve doğru komutların kullanılmasını gerektiriyordu.
OS Diskinin Kurtarma VM’ine Bağlanması
İlk olarak, orijinal VM’in işletim sistemi diskini (veya anlık görüntüsünden oluşturduğumuz yeni bir diski) kurtarma VM’imize bağladık. Bu işlem Azure portalından veya Azure CLI üzerinden yapılabilir:
# Disk adını ve kaynak grubunu belirle
OS_DISK_NAME="my-original-vm_OsDisk_1_xxxx"
RG_NAME="my-resource-group"
RECOVERY_VM_NAME="my-recovery-vm"
# Diski kurtarma VM'ine veri diski olarak bağla
az vm disk attach \
--vm-name $RECOVERY_VM_NAME \
--name $OS_DISK_NAME \
--resource-group $RG_NAME \
--sku Standard_LRS \
--query "{id:id}" -o tsv
Bağladıktan sonra, kurtarma VM'ine SSH ile bağlanıp lsblk komutuyla diskin göründüğünü doğruladık (örneğin /dev/sdc olarak).
Dosya Sistemi Kontrolü ve Onarımı (fsck)
Bağladığımız diski bir dizine bağlamadan önce, üzerinde dosya sistemi kontrolü ve onarımı yapmamız gerekiyordu. Bu işlem için fsck (file system check) komutunu kullandık:
# Diskin bölümlerini listele (genellikle sdc1 olur)
sudo fdisk -l /dev/sdc
# Dosya sistemini kontrol et ve onar
# -y parametresi tüm sorulara otomatik olarak "evet" yanıtı verir
sudo fsck -y /dev/sdc1
fsck komutu, disk üzerindeki tutarsızlıkları buldu ve otomatik olarak onarmaya çalıştı. Bu işlem, diskin boyutuna ve hasarın derecesine göre biraz zaman alabilir.
Kritik Sistem Dosyalarını Geri Yükleme/Düzeltme
Dosya sistemi onarıldıktan sonra, diski kurtarma VM'indeki bir dizine bağladık:
sudo mkdir /mnt/original_os
sudo mount /dev/sdc1 /mnt/original_os
Ardından, chroot ortamına geçerek orijinal işletim sistemi ortamında çalışmaya başladık. Bu, orijinal VM'in kök dizinini kurtarma VM'inin kök dizini gibi kullanmamızı sağladı:
# Gerekli bağlamaları yap
sudo mount --bind /dev /mnt/original_os/dev
sudo mount --bind /proc /mnt/original_os/proc
sudo mount --bind /sys /mnt/original_os/sys
# Chroot ortamına geç
sudo chroot /mnt/original_os /bin/bash
Chroot ortamında, işletim sisteminin neden başlatılamadığına dair ipuçları aradık. Kontrol ettiğimiz başlıca dosyalar şunlardı:
/etc/fstab: Yanlış disk UUID'leri veya bağlama seçenekleri önyüklemeyi engelleyebilir./boot/grub/grub.cfg: Önyükleyici yapılandırması./etc/ssh/sshd_config: SSH servisi yapılandırması./var/log/syslog,/var/log/boot.log: Sistem günlükleri.
Özellikle /etc/fstab dosyasında yanlış yapılandırılmış bir giriş bulduk ve düzelttik. Ayrıca, SSH servisiyle ilgili potansiyel sorunları gidermek için sshd_config dosyasını varsayılan ayarlarla karşılaştırıp gerekli düzenlemeleri yaptık.
Boot Loader (GRUB) Onarımı (gerekiyorsa)
Eğer sorun önyükleyici (GRUB) ile ilgiliyse, chroot ortamında GRUB'u yeniden yüklemek gerekebilir:
# GRUB'u yeniden yükle (diskin kökünü belirt)
grub-install /dev/sdc
# GRUB yapılandırmasını güncelle
update-grub
Bizim durumumuzda, fstab hatası daha baskın olduğu için GRUB onarımına gerek kalmadı, ancak bu adım ciddi önyükleme sorunlarında hayati olabilir.
SSH ve Azure Linux Agent Sorunlarını Giderme
İşletim sistemi diski üzerindeki temel sorunları giderdikten sonra, sıra SSH erişimini ve Azure Linux Agent'ı yeniden çalışır hale getirmeye geldi.
SSH Konfigürasyonunun Kontrolü ve Düzeltilmesi
Chroot ortamından çıktıktan ve diski orijinal VM'e bağlamadan önce, SSH yapılandırmasını tekrar kontrol ettik. Özellikle /etc/ssh/sshd_config dosyasında PermitRootLogin no, PasswordAuthentication no gibi güvenlik ayarlarının doğru olduğundan emin olduk. Ayrıca, SSH anahtarlarının /home/kullanici_adi/.ssh/authorized_keys dosyasında doğru olduğundan emin olduk. Yanlış bir güvenlik duvarı kuralı veya SSH servisini engelleyen başka bir uygulama olup olmadığını da kontrol ettik.
Azure Linux Agent'ın Yeniden Kurulumu/Onarımı
Azure Linux Agent'ın çalışmaması, Azure portalı üzerinden VM'i yönetmemizi engelliyordu. Bu durumda, agent'ı yeniden kurmak veya onarmak genellikle en iyi çözümdür. Chroot ortamındayken, agent'ı kaldırıp yeniden kurmayı denedik:
# Chroot ortamında (veya kurtarma VM'ine bağlıyken)
# Agent'ı kaldır
apt-get purge walinuxagent -y # Debian/Ubuntu için
yum erase walinuxagent -y # RHEL/CentOS için
# Gerekli paketleri ve agent'ı yeniden kur
apt-get update
apt-get install walinuxagent -y
Agent'ın yeniden kurulumu, genellikle onun bağımlılıklarını ve doğru yapılandırmasını da beraberinde getirir. Bu adım, VM'in Azure ile tekrar iletişim kurmasını sağlayacaktır.
Ağ Konfigürasyonunun Doğrulanması
Son olarak, ağ yapılandırmasının doğru olduğundan emin olduk. /etc/netplan/*.yaml (Ubuntu) veya /etc/sysconfig/network-scripts/ifcfg-eth0 (RHEL/CentOS) gibi dosyalarda yanlış IP adresi, ağ geçidi veya DNS ayarları önyüklemeyi veya ağ erişimini engelleyebilir. Bu dosyaları kontrol edip, Azure'ın DHCP üzerinden doğru ağ ayarlarını almasını sağlayacak şekilde yapılandırıldıklarından emin olduk.
Kurtarma Sonrası Kontroller ve Gelecek İçin Dersler
Tüm onarım işlemlerini tamamladıktan sonra, diski kurtarma VM'inden ayırıp orijinal VM'e geri bağladık ve VM'i başlattık. Bu an, tüm ekibin nefesini tuttuğu andı.
Sanal Makinenin Başlatılması ve İlk Kontroller
VM'i başlattıktan sonra, ilk olarak Boot Diagnostics ekranını kontrol ettik. Bu sefer, işletim sisteminin başarılı bir şekilde önyüklendiğini ve login prompt'unun göründüğünü görmek büyük bir rahatlama oldu. Ardından SSH ile bağlanmayı denedik ve başarılı bir şekilde erişim sağladık! Azure portalında da Agent Status'un "Ready" olarak değiştiğini gördük.
İçeri girdikten sonra, aşağıdaki kontrolleri yaptık:
dmesg: Çekirdek mesajlarını kontrol ederek herhangi bir donanım veya disk hatası olup olmadığını araştırdık.journalctl -xe: Sistem günlüklerini inceleyerek önyükleme sırasında veya sonrasında herhangi bir hata olup olmadığını kontrol ettik.systemctl status sshdvesystemctl status walinuxagent: SSH servisi ve Azure Linux Agent'ın çalıştığından emin olduk.df -hvelsblk: Disklerin doğru bağlandığını ve dosya sistemlerinin sağlıklı olduğunu doğruladık.
Uygulama Katmanı Testleri
Sistem seviyesindeki kontrollerden sonra, en önemli adım, VM üzerinde çalışan uygulamanın düzgün çalıştığını doğrulamaktı. Uygulama servislerini başlattık, loglarını kontrol ettik ve son kullanıcı erişimini test ettik. Her şeyin yolunda olduğunu gördüğümüzde, derin bir nefes alabildik.
Otomasyon ve Yedekleme Stratejilerinin Gözden Geçirilmesi
Bu olaydan önemli dersler çıkardık. Gelecekte benzer durumları önlemek veya daha hızlı çözmek için aşağıdaki adımları attık:
- Düzenli Anlık Görüntüler (Snapshots): Kritik VM'ler için daha sık ve otomatik anlık görüntü alma politikaları uyguladık.
- Otomatik Yedeklemeler: Azure Backup gibi servislerle düzenli yedeklemeleri zorunlu kıldık ve geri yükleme testleri yaptık.
- Azure Site Recovery: Felaket kurtarma senaryoları için kritik uygulamaları Azure Site Recovery ile koruma altına aldık.
- İzleme ve Uyarılar: Disk sağlığı, SSH servisi durumu ve Azure Linux Agent durumu için daha detaylı izleme ve uyarı mekanizmaları kurduk.
İzleme ve Uyarı Sistemlerinin İyileştirilmesi
Sadece VM'in "Running" olup olmadığını değil, aynı zamanda SSH servisinin erişilebilirliğini, Azure Linux Agent'ın durumunu ve disk I/O performansını da izleyen daha gelişmiş uyarılar tanımladık. Bu sayede, potansiyel sorunları çok daha erken aşamada tespit edebilecektik.
Sıkça Sorulan Sorular (SSS)
Neden hem SSH hem de Agent bozuldu?
Bu durum genellikle işletim sistemi diskindeki ciddi bozulmalardan kaynaklanır. Disk hataları, kritik sistem dosyalarının (SSH yapılandırması, agent ikili dosyaları, bağımlılıklar) zarar görmesine veya önyükleme sırasında işletim sisteminin tamamen çökmesine neden olabilir. İşletim sistemi sağlıklı bir şekilde başlayamadığında, SSH servisi de agent da doğal olarak çalışamaz.
Kurtarma VM'i kullanmak yerine başka bir yöntem var mıydı?
Azure, bazı durumlarda "Run Command" veya "Reset Password" gibi özellikleri sunar. Ancak bu özellikler, Azure Linux Agent'ın çalışır durumda olmasını gerektirir. Bizim senaryomuzda agent da bozuk olduğu için bu yöntemler işe yaramadı. Seri konsol üzerinden etkileşimli erişim mümkün olsaydı, doğrudan VM üzerinde onarım denemeleri yapılabilirdi, ancak bizim durumumuzda önyükleme takılı kaldığı için bu da mümkün değildi. Dolayısıyla, diski başka bir VM'e bağlayarak onarmak en güvenilir ve tek geçerli yöntemdi.
Bu tür bir felaketi önlemek için ne yapmalıyız?
Önleme, her zaman kurtarmadan daha iyidir:
- Düzenli Yedeklemeler ve Anlık Görüntüler: Azure Backup ve VM anlık görüntüleri ile veri kaybını önleyin ve hızlı geri dönüş noktaları oluşturun.
- İzleme ve Uyarılar: Disk I/O, CPU, bellek, disk alanı ve kritik servislerin (SSH, Agent) durumunu sürekli izleyin ve anormalliklerde uyarı alın.
- Güncelleme Yönetimi: İşletim sistemi ve uygulama güncellemelerini kontrollü bir şekilde, test ortamlarında doğrulayarak uygulayın.
- Yedekli Yapılandırmalar: Mümkünse, kritik uygulamaları birden fazla VM üzerinde (örneğin Load Balancer arkasında) çalıştırarak tek bir hata noktasını ortadan kaldırın.
- Felaket Kurtarma Planı: Bir felaket kurtarma planı oluşturun ve düzenli olarak test edin.
Veri kaybı riski ne kadardı?
Bu senaryoda veri kaybı riski oldukça yüksekti, özellikle de işletim sistemi diski fiziksel olarak bozulmuş olsaydı. Ancak anlık görüntü alarak ve diski dikkatlice onararak veri kaybını önleyebildik. Kurtarma işlemleri sırasında yapılan yanlış bir adım veya disk üzerindeki onarılamaz bir hasar, veri kaybına yol açabilirdi. Bu nedenle, kurtarma sürecine başlamadan önce mutlaka bir anlık görüntü almak kritik öneme sahiptir.