Linux Öğreniyorum Serisi 7 * Disk, Partition, File System, LVM
Merhabalar,
Linux serimiz devam ediyor. Bu yazıda Linux sistemlerde veri depolamanın temelini oluşturan disk, partition, dosya sistemi (file system) ve LVM kavramlarını ele alacağız. Önce bu kavramların birbirleriyle nasıl ilişkili olduğunu teorik olarak anlamaya çalışacağız. Ardından oluşturduğumuz Ubuntu test ortamı üzerinde aynı yapıları adım adım uygulayacağız. Amacımız yalnızca bazı Linux komutlarını çalıştırmak değil; işletim sisteminin bir diski nasıl gördüğünü, bu disk üzerinde nasıl alan oluşturulduğunu, file system’in bu yapının neresinde bulunduğunu ve LVM’in bize neden ihtiyaç duyduğumuz esnekliği sağladığını anlamak olacak. Bu anlatım belirli bir Linux dağıtımına özel olmayacaktır. Uygulamalarımızı Ubuntu üzerinde yapacak olsak da ele alacağımız disk, block device, partition, file system, mount ve LVM kavramları genel Linux mimarisinin parçalarıdır.
Hatırlatma olması açısından serinin önceki yazılarını aşağıda bulabilirsiniz:
https://asiyeyigit.com/linux-ogreniyorum-dizin-hiyerarsisi-ve-baslangic-dosyalari-ders-1/
https://asiyeyigit.com/linux-ogreniyorum-serisi-ders2/
https://asiyeyigit.com/linux-ogreniyorum-serisi-3-dosya-izinleri-ve-ozel-izinler/
https://asiyeyigit.com/linux-ogreniyorum-serisi-4-acl-access-control-list/
https://asiyeyigit.com/linux-ogreniyorum-serisi-5/
https://asiyeyigit.com/linux-ogreniyorum-serisi-6/
Bir Linux sistemde verilerimizi saklayabilmek için öncelikle fiziksel ya da sanal bir depolama alanına ihtiyaç duyarız. Bu alan fiziksel bir HDD/SSD, sanal makineye eklenmiş sanal bir disk veya bir bulut sağlayıcısının sunduğu block storage olabilir. Linux, bu depolama aygıtlarını block device (blok aygıt) olarak görür ve /dev dizini altında temsil eder. Örneğin sisteme eklenen bir disk /dev/sdb, bu disk üzerinde oluşturulan ilk partition ise /dev/sdb1 şeklinde görülür. Burada önemli olan nokta, yalnızca diskin değil, disk üzerinde oluşturulan partition’ların da işletim sistemi tarafından birer block device olarak temsil edilmesidir. Bu yazı kapsamında bir diskin Linux üzerinde kullanımını iki temel yaklaşım üzerinden ele alacağız.
Klasik disk kullanımında genel akış:
Fiziksel / Sanal Disk
↓
Block Device (/dev/sdb)
↓
Partition (/dev/sdb1) – Opsiyonel
↓
File System (ext4, XFS vb.)
↓
Mount Point (/data vb.)
↓
Linux Dizin Yapısı
Partition kullanımı zorunlu değildir. İstenirse file system doğrudan tüm block device üzerinde de oluşturulabilir:
/dev/sdb
↓
File System
↓
Mount Point
Ancak disk alanını daha esnek yönetmek istediğimizde araya LVM (Logical Volume Manager) katmanı girer. LVM sayesinde fiziksel depolama alanlarını mantıksal olarak bir araya getirebilir, bu alanlardan ihtiyacımıza göre logical volume’lar oluşturabilir ve depolama alanını daha esnek şekilde yönetebiliriz.
LVM kullanılan yapıda genel akış ise şöyledir:
Burada önemli olan nokta şudur: LVM için kullanacağımız disk veya partition üzerinde önceden bir file system oluşturmamıza gerek yoktur. Diskin tamamı veya disk üzerinde oluşturulmuş bir partition, LVM için Physical Volume (PV) olarak hazırlanabilir. File system ise LVM yapısı içerisinde oluşturduğumuz Logical Volume (LV) üzerine oluşturulur.
Linux sistemde hangi disklerin ve partition’ların bulunduğunu görmek için en sık kullanılan komutlardan biri lsblk komutudur. lsblk, sistemdeki block device’ları ve bunların birbirleriyle olan ilişkilerini ağaç yapısında gösterir. Böylece hangi diskin hangi partition’lara sahip olduğunu, disk boyutlarını ve varsa mount noktalarını kolayca görebiliriz. Şimdi Ubuntu test sistemimiz üzerinde mevcut block device’ları görüntüleyelim;
lsblk çıktısına baktığımızda sda isimli 30 GB’lık diskin işletim sistemi diski olduğunu ve üzerinde /, /boot/efi ve /boot için kullanılan partition’ların bulunduğunu görüyoruz. Bunun dışında sdb, sdc, sdd ve sde isimli dört adet 4 GB’lık data disk sistem tarafından algılanmış durumda. Bu disklerin altında herhangi bir partition görünmemesi ve MOUNTPOINTS alanlarının boş olması, disklerin henüz partition’lanmadığını, üzerlerinde bir file system oluşturulmadığını ve herhangi bir dizine mount edilmediğini gösteriyor. TYPE alanındaki disk ve part ifadeleri de sırasıyla fiziksel/sanal diskleri ve bu diskler üzerindeki partition’ları temsil ediyor. Çıktının sonunda görülen sr0 ise sanal CD/DVD-ROM aygıtıdır ve bu çalışma kapsamında kullanılmayacaktır.
Partition, bir diskin kullanım alanını mantıksal bölümlere ayırmamızı sağlar. Örneğin /dev/sdb diskin tamamını ifade ederken, bu disk üzerinde oluşturulan ilk partition /dev/sdb1 olarak görünür. Partition bilgileri diskin üzerindeki partition table içerisinde tutulur; güncel sistemlerde çoğunlukla GPT (GUID Partition Table) kullanılır, daha eski sistemlerde ise MBR ile karşılaşılabilir. Tek bir diskin tamamını tek partition olarak kullanabileceğimiz gibi, farklı amaçlar için birden fazla partition da oluşturabiliriz. Biz ilk data diskimiz olan /dev/sdb üzerinde bir partition oluşturarak klasik disk kullanımını göstereceğiz. Önce diskin şu anki durumuna bakalım:
Bu çıktı /dev/sdb diskinin sistem tarafından 4 GiB boyutunda bir sanal disk olarak algılandığını gösteriyor. Diskte toplam 8,388,608 sektör bulunuyor; mantıksal sektör boyutu 512 byte, fiziksel sektör boyutu ise 4096 byte. Çıktıda herhangi bir partition listelenmediği için /dev/sdb şu anda tamamen boş ve henüz bir partition table ya da partition içermiyor. Şimdi bu disk üzerinde ilk partition’ı oluşturalım.
Burada önemli bir nokta yakaladık: fdisk, diskte mevcut bir partition table bulamadığı için bellekte otomatik olarak DOS/MBR tablosu hazırlamış. Henüz diske hiçbir şey yazılmadı. Biz güncel bir yapı kuracağımız için MBR yerine GPT kullanalım.
Sıradaki adımda yeni bir partition oluşturacağız. Command (m for help): satırında sadece n yazacağız.
fdisk ile /dev/sdb üzerinde GPT partition table oluşturduk ve diskin tamamını kullanacak şekilde yaklaşık 4 GiB boyutunda ilk partition olan /dev/sdb1’i tanımladık. fdisk değişiklikleri önce bellekte tutar; bu nedenle bu aşamada yapı henüz kalıcı değildir. Şimdi Command (m for help): satırında w yazacağız. Bu komut partition table değişikliklerini diske kaydeder ve fdisk’ten çıkar. İşlem sonrası /dev/sdb1’in oluştuğunu görüyoruz.
Aynı işlemi /dev/sdc, /dev/sdd ve /dev/sde diskleri için de tekrarlayarak her disk üzerinde birer GPT partition oluşturduk. Böylece sırasıyla /dev/sdc1, /dev/sdd1 ve /dev/sde1 partition’ları hazır hale geldi.
File system, bir block device üzerindeki alanın dosya ve dizinler halinde kullanılabilmesini sağlayan yapıdır. Dosyaların isimleri, konumları, boyutları ve çeşitli metadata bilgileri file system tarafından yönetilir. Linux dünyasında yaygın olarak ext4 ve XFS kullanılır. Biz klasik disk kullanımını göstermek için /dev/sdb1 üzerinde ext4 oluşturacağız.
mkfs.ext4 komutu ile /dev/sdb1 partition’ı üzerinde ext4 file system oluşturduk. Çıktıda file system için bir UUID üretildiğini, inode yapılarının ve journal alanının oluşturulduğunu görüyoruz. Artık /dev/sdb1 üzerinde kullanılabilir bir file system mevcut; ancak henüz Linux dizin yapısına bağlanmış değil.
df -hT /data1 çıktısında /dev/sdb1 partition’ının ext4 file system ile biçimlendirildiğini ve /data1 dizinine başarıyla mount edildiğini görüyoruz. Yaklaşık 3.9 GiB kullanılabilir alan mevcut ve disk artık Linux dizin yapısı üzerinden erişilebilir durumda.
azureuser@vm-ubuntu-storage-lab:~$ sudo blkid /dev/sdb1
/dev/sdb1: UUID=”Gn2NdV-iGK4-BvKT-JwSo-Via5-5fs2-ViQT2w” TYPE=”LVM2_member” PARTUUID=”cbc66302-1606-4d20-8605-051255129175″
azureuser@vm-ubuntu-storage-lab:~$
blkid çıktısı bize /dev/sdb1 için file system’in ext4 olduğunu ve file system’e ait UUID değerini gösteriyor. Kalıcı mount tanımlarında /dev/sdb1 gibi device adları yerine UUID kullanmak daha güvenlidir; çünkü device isimleri bazı durumlarda değişebilir.
Şimdi /etc/fstab dosyasına bu diski ekleyelim.
Şimdi /etc/fstab dosyasının çalıştığını test edelim.
/etc/fstab dosyasına UUID üzerinden kalıcı mount tanımını ekledikten sonra mevcut mount işlemini kaldırdık ve mount -a ile tanımı test ettik. findmnt /data1 çıktısında /dev/sdb1 partition’ının ext4 file system ile /data1 dizinine yeniden mount edildiğini görüyoruz. Böylece disk, sistem yeniden başlatıldığında da aynı mount point üzerinden kullanılabilecek şekilde kalıcı hale getirildi.
LVM (Logical Volume Manager), disk alanını fiziksel disk sınırlarından bağımsız ve daha esnek yönetmemizi sağlayan bir katmandır. Temel yapı PV (Physical Volume) → VG (Volume Group) → LV (Logical Volume) şeklindedir. Bir veya birden fazla disk/partition PV olarak hazırlanır, bunlar bir VG altında birleştirilir ve bu ortak kapasiteden ihtiyaca göre LV’ler oluşturulur. File system ise bu LV’lerin üzerine kurulur.
/dev/sdc1, /dev/sdd1 ve /dev/sde1 partition’larını pvcreate komutu ile Physical Volume (PV) haline getirdik. Şimdi bu üç PV’yi tek bir Volume Group altında birleştirelim:
vgcreate komutu ile /dev/sdc1, /dev/sdd1 ve /dev/sde1 Physical Volume’larını vg_data isimli tek bir Volume Group altında birleştirdik. vgs çıktısında bu Volume Group’un 3 PV içerdiğini, henüz herhangi bir Logical Volume oluşturulmadığını ve toplam yaklaşık 12 GiB alanın tamamının boş olduğunu görüyoruz. Şimdi bu havuzdan ilk Logical Volume’u oluşturalım. Örneğin 4 GiB’lık bir LV:
lvcreate komutu ile vg_data Volume Group içerisinden 4 GiB boyutunda lv_data isimli bir Logical Volume (LV) oluşturduk. lvs çıktısında bu Logical Volume’un vg_data altında yer aldığını ve 4 GiB kapasiteye sahip olduğunu görüyoruz. İlk lvs komutunu normal kullanıcı ile çalıştırdığımızda yetki uyarısı aldığımız için LVM sorgularını sudo ile çalıştırıyoruz.
lvcreate komutu ile vg_data Volume Group içerisinden 4 GiB boyutunda lv_data isimli bir Logical Volume oluşturduk. Ancak bu Logical Volume varsayılan olarak linear yapıdadır; yani henüz herhangi bir RAID koruması bulunmamaktadır. Volume Group yalnızca fiziksel disk alanlarını ortak bir havuzda toplar, tek başına disk arızasına karşı koruma sağlamaz. LVM’de RAID seviyesi Logical Volume oluşturulurken belirlenir. Bu nedenle sonraki adımda linear LV ile RAID5/RAID10 yapıları arasındaki farkı uygulamalı olarak göstereceğiz.
lvremove ile korumasız olarak oluşturduğumuz linear lv_data Logical Volume’u kaldırdık. Bu işlem Volume Group veya Physical Volume’ları silmez; yalnızca ilgili LV’yi kaldırır ve kullandığı alanı tekrar vg_data havuzuna kazandırır. Şimdi aynı havuz üzerinde disk arızasına karşı koruma sağlayan bir LVM RAID5 Logical Volume oluşturacağız. Şimdi 3 PV üzerinde RAID5 oluşturalım:
lvcreate –type raid5 komutu ile vg_data içerisinde 4 GiB kullanılabilir kapasiteye sahip lv_raid5 isimli RAID5 Logical Volume oluşturduk. -i 2 parametresi iki data stripe kullanılacağını belirtir; RAID5 parity için bir disk daha kullandığından yapı toplam üç Physical Volume üzerine yayılır. Böylece disklerden birinin arızalanması durumunda veriler parity bilgisi kullanılarak erişilebilir durumda kalabilir. Çıktıda ayrıca LVM’in varsayılan olarak 64 KiB stripe size kullandığını görüyoruz. RAID5 kapasitesinin bir bölümü parity için kullanıldığından fiziksel olarak tüketilen alan, Logical Volume’un görünen 4 GiB kapasitesinden daha fazladır. RAID yapısının veri yedeklemesi olmadığını, yalnızca disk arızasına karşı süreklilik sağladığını da özellikle belirtmek gerekir. Şimdi yapının gerçekten raid5 olduğunu görelim:
Bu çıktı RAID5 yapısının gerçekten üç Physical Volume üzerine dağıtıldığını doğruluyor. lv_raid5 4 GiB kullanılabilir kapasiteye sahipken LVM, /dev/sdc1, /dev/sdd1 ve /dev/sde1 üzerinde yaklaşık 2 GiB’lık üç RAID image oluşturmuş; RAID5’te bunların toplamından iki birim veri kapasitesi elde edilirken kalan kapasite parity bilgisi için kullanılır. Parity tek bir diske sabitlenmez, stripe’lar arasında dağıtılır. Ayrıca her disk üzerinde RAID durum bilgilerinin tutulduğu küçük rmeta metadata alanları bulunur. Böylece yapı üç diske yayılmış ve tek disk arızasına dayanabilecek RAID5 korumasına kavuşmuştur.
Şimdi RAID5 Logical Volume’un üzerine file system oluşturalım. Burada önemli nokta, file system’in artık fiziksel diskler üzerine değil, RAID5 olarak oluşturduğumuz Logical Volume üzerine gelmesidir.
mkfs.ext4 komutu ile RAID5 olarak oluşturduğumuz lv_raid5 Logical Volume üzerine ext4 file system oluşturduk. Böylece file system artık tek tek fiziksel diskleri değil, LVM tarafından RAID5 mantığıyla sunulan mantıksal alanı kullanıyor. Bu yapı tek disk arızasına karşı dayanıklıdır; ancak RAID’in bir yedekleme yöntemi olmadığını, yalnızca disk seviyesinde süreklilik sağladığını unutmamak gerekir. Şimdi mount edelim:
lv_raid5 Logical Volume’unu /raid5 dizinine mount ettikten sonra df -hT çıktısında ext4 file system’in yaklaşık 3.9 GiB boyutunda ve kullanılabilir durumda olduğunu görüyoruz. Fiziksel tarafta üç disk RAID5 yapısında kullanılsa da parity nedeniyle Logical Volume’un kullanılabilir kapasitesi toplam fiziksel kapasiteden daha düşüktür. Bu alan artık Linux dizin yapısı üzerinden /raid5 altında erişilebilir durumdadır.
RAID5’in gerçekten disk arızasına dayanıp dayanmadığını uygulamalı gösterelim. Ama diski hemen devre dışı bırakmadan önce RAID’in sağlıklı ve senkron durumda olduğunu terminalden belgeleyelim.
Çalışmamıza bir süre ara verdiğimiz için test sistemimizi power-off durumuna getirmiştik. Sistemi tekrar power-on yaptıktan sonra Linux’un disklere verdiği /dev/sdX isimlerinin önceki oturuma göre değiştiğini gördük. Ancak fiziksel/sanal disklerin kendisi değişmemişti; yalnızca kernel tarafından verilen device isimleri farklılaşmıştı. pvs ve lsblk -f çıktıları LVM Physical Volume’larının ve vg_data-lv_raid5 Logical Volume’unun hâlâ mevcut olduğunu doğruladı. Buna karşılık /data1, /etc/fstab içinde UUID ile kalıcı olarak tanımlandığı için sistem açılışında otomatik olarak mount edilirken, /raid5 için henüz kalıcı mount tanımı yapılmadığından bu alan otomatik olarak bağlanmadı. Bu durum, /dev/sdX isimlerinin kalıcı disk kimliği olarak kullanılmaması ve reboot sonrasında gerekli file system’lerin /etc/fstab üzerinden kalıcı olarak tanımlanması gerektiğini uygulamalı olarak göstermiş oldu.
Bu nedenle şimdi RAID5 Logical Volume’umuzu da UUID kullanarak kalıcı şekilde `/raid5` dizinine bağlayacağız.
Buradaki nofail seçeneği, ilgili file system veya block device boot sırasında erişilebilir durumda değilse mount işleminin başarısız olmasının sistem açılışını kritik şekilde engellememesine yardımcı olur. Bu seçenek özellikle işletim sistemi için zorunlu olmayan data disklerinde tercih edilebilir. Ancak production sistemlerinde kullanımı, uygulamanın ilgili mount point’e bağımlılığı ve servislerin başlatılma sırası dikkate alınarak değerlendirilmelidir.
RAID5 yapımızı oluşturup file system’i `/raid5` altında kullanıma açtık. Şimdi RAID5’in temel avantajlarından biri olan tek disk arızasına karşı dayanıklılığı uygulamalı olarak test edeceğiz. Test sırasında önce RAID5 üzerinde bir dosya oluşturup dosyanın checksum değerini alacağız. Ardından RAID yapısındaki Physical Volume’lardan birini sistemden geçici olarak devre dışı bırakarak tek disk kaybını simüle edeceğiz. Sonrasında Logical Volume’un erişilebilir durumda olup olmadığını ve test dosyamızın içeriğinin değişmeden okunup okunamadığını kontrol edeceğiz. Bu testin amacı RAID’in bir backup mekanizması olduğunu göstermek değil; RAID5’in tek bir fiziksel disk kaybında servisin ve veriye erişimin devam etmesini nasıl sağlayabildiğini gözlemlemektir.
`lvs` çıktısında `lv_raid5` Logical Volume’unun `raid5` tipinde olduğunu ve `Cpy%Sync` değerinin `%100` olduğunu görüyoruz. Bu değer RAID bileşenlerinin tamamen senkronize olduğunu ve disk arızası testine sağlıklı bir başlangıç yaptığımızı gösterir. Ardından `/raid5` üzerinde bir test dosyası oluşturduk ve dosyanın SHA-256 checksum değerini `ada566712711f58c2cc1d2beb4dcf06b2142a87c0d6f24ad49211e4b650f1cb9` olarak kaydettik. Disk arızası simülasyonundan sonra aynı dosyayı yeniden okuyup checksum değerini karşılaştırarak verinin bütünlüğünü kontrol edeceğiz.
`/dev/sdd` diskini sistemden çıkardıktan sonra `lsblk` çıktısında ilgili diskin artık görünmediğini, LVM tarafında ise RAID bileşenlerinden birinin `[unknown]` olarak işaretlendiğini görüyoruz. `lvs` çıktısında `lv_raid5` Logical Volume’unun `Health` durumu `partial` olarak değişmiş olsa da volume aktif kalmaya devam ediyor. Buna rağmen `/raid5` mount point’i erişilebilir durumda ve test dosyamızı sorunsuz şekilde okuyabiliyoruz. Bu sonuç, RAID5 yapısının tek disk kaybı sonrasında degraded durumda çalışmaya devam ederek veriye erişimi koruyabildiğini uygulamalı olarak göstermektedir.
Disk arızası sonrasında test dosyasının SHA-256 checksum değerini yeniden aldığımızda, arıza öncesindeki ada566712711f58c2cc1d2beb4dcf06b2142a87c0d6f24ad49211e4b650f1cb9 değeriyle tamamen aynı olduğunu görüyoruz. Böylece RAID5 degraded durumda çalışırken test dosyasına erişimin devam ettiğini ve bu dosyanın içeriğinin disk kaybı sırasında değişmediğini doğrulamış olduk.
SCSI bus’ı yeniden tarattığımızda daha önce sistemden çıkardığımız disk tekrar algılandı; ancak bu kez `/dev/sdd` yerine `/dev/sdf` adıyla sisteme eklendi. `pvs` çıktısında PV UUID değerinin değişmediğini gördüğümüz için LVM diski aynı Physical Volume olarak doğru şekilde tanıdı. `lvs` çıktısında `partial` durumunun ortadan kalktığını ve `Cpy%Sync` değerinin yeniden `%100` olduğunu görüyoruz. Böylece RAID5 yapımız tekrar tam ve sağlıklı duruma dönmüş oldu. Bu test aynı zamanda `/dev/sdX` isimlerinin kalıcı disk kimliği olmadığını, LVM’in diskleri kendi metadata ve PV UUID bilgileri üzerinden takip ettiğini uygulamalı olarak göstermiş oldu.
Production ortamlarında RAID5 tek disk arızasına karşı süreklilik sağlasa da, arıza sonrasında yapı degraded durumda çalıştığı için ikinci bir disk kaybına karşı koruma kalmaz. Bu nedenle arızalı diskin mümkün olduğunca hızlı değiştirilmesi ve RAID yapısının yeniden sağlıklı duruma getirilmesi gerekir. Ayrıca RAID, yanlışlıkla silinen dosyalar, uygulama hataları veya veri bozulması gibi durumlara karşı yedekleme sağlamaz; bu nedenle RAID ve backup birbirinin alternatifi değil, birbirini tamamlayan veri koruma katmanlarıdır.
Klasik file system kullanımını göstermek için kullandığımız `/data1` alanına artık ihtiyaç duymadığımızdan bu file system’i unmount ettik ve `/etc/fstab` üzerindeki kalıcı mount tanımını kaldırdık. Ardından eski ext4 imzasını temizleyerek `/dev/sda1` partition’ını yeni bir LVM Physical Volume olarak hazırladık ve `vg_data` Volume Group’una ekledik. `pvs` çıktısında artık dört Physical Volume bulunduğunu görüyoruz. Böylece dört disk gerektiren RAID10 yapısını oluşturmak için gerekli altyapı hazır hale geldi.
RAID10, striping + mirroring yapısını birlikte kullanır. LVM RAID10 için minimum dört cihaz gerekir. -i 2 iki stripe, -m 1 ise her veri parçasının bir ek mirror kopyasının tutulmasını sağlar. Biz 2 GiB usable RAID10 oluşturalım:
`lvcreate` komutu ile dört Physical Volume üzerinde 2 GiB kullanılabilir kapasiteye sahip `lv_raid10` Logical Volume oluşturduk. `lvs` çıktısında RAID10 yapısının dört ayrı `rimage` ve bunlara ait metadata alanlarından oluştuğunu görüyoruz. Her `rimage` yaklaşık 1 GiB kapasiteye sahip olduğundan 2 GiB kullanılabilir Logical Volume için yaklaşık 4 GiB fiziksel alan kullanılmaktadır. Bunun nedeni RAID10’un veriyi stripe ederken aynı zamanda mirror kopyalarını da tutmasıdır. Çıktı alındığı sırada `Cpy%Sync` değerinin `%85.58` olması RAID10’un ilk senkronizasyon işleminin henüz devam ettiğini göstermektedir.
RAID10 oluşturulduktan sonra senkronizasyon durumunu tekrar kontrol ettiğimizde `Cpy%Sync` değerinin `%100` seviyesine ulaştığını ve yapının tamamen senkronize olduğunu görüyoruz. Ardından `lv_raid10` Logical Volume üzerine ext4 file system oluşturduk ve `/raid10` dizinine mount ettik. `df -hT` çıktısında yaklaşık 2 GiB büyüklüğündeki RAID10 alanının ext4 file system ile başarıyla kullanılabilir hale geldiğini görüyoruz. Böylece dört Physical Volume üzerinde striping ve mirroring özelliklerini birlikte kullanan RAID10 yapımız tamamlanmış oldu.
RAID10 üzerinde disk arızası testine başlamadan önce `/raid10` altında bir test dosyası oluşturduk ve SHA-256 checksum değerini `44de2c9f5293dc423613ea444e53973df49c7f97585ad7ba41ffd7ca463d467c` olarak kaydettik. `lvs` çıktısı `lv_raid10` Logical Volume’unun dört ayrı RAID image üzerinden çalıştığını doğruluyor. Bir sonraki adımda RAID10 üyelerinden birini sistemden geçici olarak çıkararak tek disk kaybını simüle edecek ve hem veriye erişimin hem de dosya bütünlüğünün korunup korunmadığını kontrol edeceğiz.
`/dev/sda` diskini sistemden çıkardıktan sonra `lvs` çıktısında RAID10 yapısının `partial` duruma geçtiğini ve ilgili `rimage` ile `rmeta` bileşenlerinin `[unknown]` olarak işaretlendiğini görüyoruz. Buna rağmen `lv_raid10` aktif kalmaya devam etmiş, `/raid10` mount point’i erişilebilir durumda kalmış ve test dosyamız sorunsuz şekilde okunabilmiştir. Disk kaybı öncesinde aldığımız SHA-256 checksum değeri ile arıza sonrasında elde ettiğimiz değerin aynı olması da test dosyasının içeriğinin değişmediğini doğrulamaktadır. Böylece RAID10’un tek disk kaybında degraded durumda çalışmaya devam ederek veri erişimini koruyabildiğini uygulamalı olarak göstermiş olduk.
SCSI bus yeniden tarandığında çıkardığımız disk tekrar sisteme dahil oldu; ancak bu kez `/dev/sda1` yerine `/dev/sdg1` adıyla görüldü. Buna rağmen Physical Volume UUID değerinin değişmemesi sayesinde LVM diski doğru şekilde tanıdı ve RAID10 bileşenini yeniden yapıya dahil etti. `lvs` çıktısında `partial` durumunun ortadan kalktığını ve `Cpy%Sync` değerinin tekrar `%100` olduğunu görüyoruz. Böylece RAID10 yapımız yeniden tam ve sağlıklı duruma dönmüş oldu. Bu test aynı zamanda `/dev/sdX` isimlerinin kalıcı disk kimliği olmadığını bir kez daha uygulamalı olarak göstermiş oldu.
RAID5 kapasite kullanımını daha verimli hale getirirken parity hesaplamasının getirdiği ek write maliyetine sahiptir. RAID10 ise kullanılabilir kapasitenin yaklaşık yarısını mirror kopyaları için ayırmasına karşılık özellikle write performansı ve recovery süreci açısından daha avantajlıdır. Hangi RAID seviyesinin tercih edileceği yalnızca disk sayısına göre değil; kapasite, performans, hata toleransı ve uygulamanın iş gereksinimleri birlikte değerlendirilerek belirlenmelidir.
Bu çalışmada Linux depolama mimarisini fiziksel veya sanal diskten başlayarak partition, file system, mount ve LVM katmanlarına kadar uygulamalı olarak inceledik. Klasik disk kullanımında ext4 file system oluşturup UUID üzerinden kalıcı mount işlemini gerçekleştirdik; ardından Physical Volume, Volume Group ve Logical Volume kavramlarını kullanarak LVM yapısını oluşturduk. LVM’in yalnızca disk alanlarını esnek şekilde yönetmek için değil, RAID özellikleriyle disk arızalarına karşı dayanıklı Logical Volume’lar oluşturmak için de kullanılabildiğini RAID5 ve RAID10 örnekleri üzerinde gördük. Gerçekleştirdiğimiz disk arızası simülasyonlarında Logical Volume’ların degraded durumda çalışmaya devam ettiğini, file system’lere erişimin sürdüğünü ve checksum kontrolleriyle test verilerimizin değişmediğini doğruladık. Ayrıca çalışma sırasında disklerin `/dev/sdX` isimlerinin sistem yeniden başlatıldığında veya yeniden algılandığında değişebildiğini; buna karşılık UUID ve LVM metadata bilgilerinin depolama bileşenlerinin doğru şekilde tanınmasını sağladığını uygulamalı olarak gözlemledik. Son olarak RAID’in bir backup yöntemi olmadığını tekrar hatırlamak gerekir. RAID donanım veya disk seviyesindeki arızalara karşı erişilebilirlik ve süreklilik sağlar; ancak yanlışlıkla veri silinmesi, uygulama kaynaklı bozulmalar veya felaket senaryoları için ayrıca uygun bir backup ve disaster recovery stratejisi oluşturulmalıdır.
Sarav Asiye Yiğit * 30 Ağustos 2026