ÇALIŞMA NOTLARI / SANALLAŞTIRMA & DEPOLAMA
KVM’de depolama mimarisini yenilemek
ext4 üzerinde QCOW2 dosyalarıyla tutulan sanal disklerden, LVM mantıksal birimlerine (logical volumes) geçiş. Eclit’te üzerinde çalıştığımız altyapı modernizasyonunun mimarisi ve geçiş planı.
Ne değişiyor?
Çalışmanın odağında sanal disklerin ana makine (host) üzerinde nasıl tutulduğu var. Mevcut yapıda sanal diskler, ext4 ile biçimlendirilmiş bir bölümde QCOW2 dosyaları olarak yer alıyor. Hedef yapıda diskleri LVM mantıksal birimleri üzerinde yönetiyor, paylaşımlı depolamayla birlikte ele alıyoruz.
MEVCUT YAPI
ext4 + QCOW2
Ana makinedeki dosya sistemi üzerinde sanal disk dosyaları. Mevcut kurulumda düğümler arasında paylaşılmayan depolama.
HEDEF YAPI
Paylaşımlı depolama + LVM
Blok seviyesinde yönetilen mantıksal birimler. Küme düğümlerinin erişebildiği depolama üzerinde daha düzenli kapasite yönetimi.
Buradaki “ext4’ten LVM’e” ifadesi bir mimari değişimin kısa adı. ext4 bir dosya sistemi, QCOW2 bir sanal disk biçimi, LVM ise mantıksal birim yöneticisi (Logical Volume Manager). Konuk işletim sisteminin (guest) içindeki dosya sistemi bu değişimden ayrı bir katman.
Depolama ve yüksek erişilebilirlik
Hedefimiz depolama katmanlarını sadeleştirmek, kapasiteyi daha öngörülebilir yönetmek ve yüksek erişilebilirlik (high availability, HA) için uygun bir temel oluşturmak. Paylaşımlı depolama, düğümler arası taşımalarda sanal disk verilerinin yeniden kopyalanması ihtiyacını azaltıyor.
Canlı taşıma (live migration) da yalnızca depolamaya bağlı değil. İşlemci uyumluluğu, ağ bağlantıları ve sanal makinelere bağlı yerel aygıtlar geçiş planının parçası. Performans farkı ise iş yüküne göre ölçülmeli; yalnızca disk biçimini değiştirmek belirli bir kazancı garanti etmiyor.
Geçişi nasıl planlıyoruz?
Depolama dönüşümü ile platform yükseltmesini aynı bakım penceresinde ele alıyoruz. Süreci küçük bir pilotla doğrulayıp aşamalı olarak yaygınlaştırmayı hedefleyen plan beş adımdan oluşuyor:
- Hazırlık. Sunucu envanterinin, erişimlerin, yedekleme akışlarının ve otomasyon bağımlılıklarının çıkarılması.
- Pilot. Sınırlı sayıda sunucuda geçiş adımlarının denenmesi ve sonuçların doğrulanması.
- İlk faz. Pilotun ardından belirlenen sunucu grubunun aynı geçiş planıyla taşınması ve platformun yükseltilmesi.
- Doğrulama. Sanal makinelerin, erişimlerin ve Proxmox Backup Server (PBS) yedekleme akışlarının uçtan uca sınanması.
- Yaygınlaştırma. Doğrulanan adımların sonraki sunucu gruplarına uygulanması.
Diskler kadar erişimler de değişiyor
Ana makineler yeniden kurulduğunda SSH sunucu anahtarları (host keys) da değişiyor. Bu nedenle geçiş planı disk taşımayla sınırlı kalmıyor: kullanıcı erişimleri, known_hosts kayıtları, yapılandırma yönetimi araçları ve otomatik bağlantı kuran betikler de gözden geçiriliyor.
Yeni anahtar parmak izleri güvenilir bir kanaldan doğrulanmalı. Anahtar denetimini kapatmak yerine ilgili kayıtlar doğrulama sonrasında güncellenmeli; otomasyon bağlantıları da bakım sonrasında ayrıca sınanmalı.
Anlık görüntü, yedek ve kapasite
Anlık görüntü (snapshot) ve klonlama olanakları, depolama arka ucuna (backend) ve platform yapılandırmasına göre değişiyor. Klasik LVM ile LVM-thin aynı davranışı göstermiyor. Bu yüzden geçişten önce kullanılan özelliklerin hedef yapıda nasıl karşılanacağı belirlenmeli.
Çalışmamızda PBS yedekleme akışları da doğrulama kapsamına giriyor. Bir anlık görüntü, bağımsız bir yedeğin yerine geçmiyor; geri yükleme (restore) adımlarını sınamak da yedekleme planının parçası olmalı.
Kapasite artırımı da sanal diskten konuk içindeki bölüm ve dosya sistemine kadar tüm katmanlarda değerlendirilir. Çevrim içi (online) büyütmenin mümkün olup olmadığı, kullanılan sürücüye ve dosya sistemi düzenine bağlıdır.
Bu çalışmanın odağı
Disk mimarisindeki değişimi; yedekleme, erişim yönetimi ve bakım süreçleriyle birlikte ele almak. Aşamalı geçiş planı, her adımı doğrulayarak sonraki sunucu grubuna uygulanabilir bir yöntem oluşturmayı amaçlıyor.