Lenovo sunucu projelerinde, özellikle KOBİ ve orta ölçekli işletmeler için çözüm tasarlarken, sıklıkla yapılan bir gözlemim var: müşteriler genellikle CPU seçimine aşırı odaklanıyor. “Kaç çekirdek olacak?”, “Turbo Boost kaç GHz’e çıkıyor?” gibi sorular ilk sırada geliyor. Ancak benim tecrübelerime göre, bir sunucunun genel performansını ve iş yükü altındaki tepki süresini asıl belirleyen faktör, CPU’dan ziyade doğru planlanmış disk altyapısıdır.
Bir sunucu, sadece işlemci gücüyle değil, aynı zamanda bellek, ağ ve en önemlisi depolama birimlerinin uyumlu çalışmasıyla verimli olur. Yavaş bir disk altyapısı, en güçlü işlemciyi bile darboğaza sokarak tüm sistemin performansını düşürebilir. Bu nedenle, bir Lenovo sunucu projesinde ilk adımımız her zaman iş yükünün depolama gereksinimlerini derinlemesine analiz etmek oluyor.
İş Yükünü Anlamak: CPU’dan Önce Disk İhtiyaçları
Bir sunucu projesine başlarken ilk sorumuz her zaman “Bu sunucu ne iş yapacak?” olur. Ardından gelen “Bu iş yükü disk I/O’sunu ne kadar kullanacak?” sorusu, CPU çekirdek sayısından veya saat hızından çok daha belirleyicidir. Çoğu KOBİ ve orta ölçekli işletme uygulamasında, işlemci sürekli %100 yük altında çalışmaz; ancak veritabanı, dosya sunucusu veya ERP uygulamaları sürekli disk erişimi gerektirir.
Örneğin, bir muhasebe yazılımı veya ERP sistemi, yoğun işlemci gücünden ziyade, saniyede binlerce küçük veri bloğunu okuma ve yazma (random I/O) kapasitesine ihtiyaç duyar. Bu tür iş yükleri için, yüksek IOPS (saniyedeki giriş/çıkış işlemleri) sunan hızlı depolama çözümleri, birkaç çekirdek daha fazla olan bir işlemciden çok daha kritik performans artışı sağlar. Eğer disk altyapısı bu talebi karşılayamazsa, uygulamalar yavaşlar ve kullanıcılar gecikmeler yaşar, işlemci ise boşta kalır.
Tipik bir sanallaştırma ortamında çalışan birden fazla sanal makineyi düşünelim. Her sanal makine kendi işletim sistemi ve uygulamalarıyla disk I/O’su üretir. Bu durumda, temel sunucunun disk altyapısı bu birleşik I/O yükünü kaldırabilmelidir. Eğer altyapı yetersiz kalırsa, her sanal makine kendi içinde “donuyormuş” gibi bir his verir, oysa sunucunun CPU kullanımı %20’leri geçmeyebilir. Bu durum, CPU’nun diskten veri beklediği için boşta kalmasından kaynaklanır.
RAID Seviyeleri ve Performansın Kesişimi
Lenovo sunucularda disk planlaması yaparken, seçilen RAID (Redundant Array of Independent Disks) seviyesi, hem performans hem de veri güvenliği açısından hayati öneme sahiptir. Her RAID seviyesinin farklı performans karakteristiği vardır ve bu, iş yükünün türüne göre dikkatlice seçilmelidir. Benim sahadaki yaklaşımım, genellikle performans ve yedeklilik arasında en iyi dengeyi sunan RAID seviyelerini tercih etmektir.
Örneğin, RAID 10 (RAID 1+0), hem yüksek okuma/yazma performansı hem de veri yedekliliği sunar. Disk grubunun yarısının arızalanmasına kadar dayanıklıdır ve yazma performansı RAID 5 veya RAID 6’ya göre çok daha iyidir, çünkü yazma cezası (write penalty) yoktur. Bu, özellikle yüksek IOPS gerektiren veritabanı sunucuları veya sanallaştırma platformları için idealdir. Ancak, RAID 10’da disk kapasitesinin yarısı yedeklilik için kullanılır, bu da maliyeti artırabilir.
# Tipik bir RAID kontrolcü CLI çıktısı (örneğin LSI MegaRAID)
# RAID 10 yapılandırması örneği:
MegaCli -LDInfo -Lall -aALL
Adapter #0
Logical Drive #0 (Target Id 0):
RAID Level : Primary-1, Secondary-0, RAID Level Qualifier-0
Size : 1.817 TB
State : Optimal
Strip Size : 256 KB
Number of PDs : 4
Span Depth : 2
Default Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Access Policy : Read/Write
Disk Cache Policy : Enabled
Encryption Type : NoneDiğer yandan, RAID 5 veya RAID 6, daha fazla kullanılabilir kapasite sunarken, yazma performansı açısından bir miktar taviz verir. RAID 5’te tek disk arızası, RAID 6’da ise iki disk arızası tolere edilebilir. Ancak her yazma işleminde parite hesaplaması ve yazılması gerektiği için, özellikle küçük rastgele yazmalarda performans düşüşü yaşanabilir. Bu durum, özellikle yoğun transaction’lı veritabanları için darboğaz yaratabilir. Bu sebeple, kritik uygulamalarda RAID 10, daha az I/O yoğunluğu olan dosya sunucularında ise RAID 5 veya RAID 6 tercih ederim.
Disk Tipleri ve Teknolojinin Rolü: HDD’den NVMe’ye
Günümüzde Lenovo sunucularda kullanabileceğimiz disk teknolojileri oldukça çeşitlidir ve her birinin kendine özgü avantajları ve dezavantajları bulunur. Doğru disk tipini seçmek, sunucunun beklenen performansını doğrudan etkiler. Benim için bu seçim, her zaman iş yükünün gereksinimleri ile bütçe arasında bir denge kurmayı içerir.
Geleneksel HDD’ler (Hard Disk Drives), yüksek kapasite ve düşük maliyet sunar, ancak IOPS ve gecikme süresi (latency) açısından SSD’lerin gerisindedir. Genellikle arşiv depolama, büyük dosya sunucuları veya yedekleme hedefleri gibi yüksek kapasite, düşük erişim hızı gerektiren senaryolarda tercih edilirler. Kurumsal sınıf SAS HDD’ler, SATA HDD’lere göre daha yüksek IOPS ve güvenilirlik sunar.
SSD’ler (Solid State Drives), HDD’lere kıyasla çok daha yüksek IOPS, daha düşük gecikme ve daha iyi dayanıklılık sunar. SATA SSD’ler, HDD’lerden belirgin şekilde hızlıdır ve çoğu genel amaçlı sunucu iş yükü için yeterli performansı sağlar. SAS SSD’ler, kurumsal ortamlarda daha yüksek performans, güvenilirlik ve çift port desteği sunarak daha kritik uygulamalar için uygundur. NVMe (Non-Volatile Memory Express) SSD’ler ise, PCIe arayüzünü kullanarak en yüksek performansı, en düşük gecikmeyi ve en yüksek IOPS değerlerini sunar. Özellikle ultra-yüksek performans gerektiren veritabanları, büyük veri analizi veya yapay zeka iş yükleri için NVMe SSD’ler vazgeçilmezdir.
Tipik bir karşılaştırma tablosu (temsili değerler):
| Disk Tipi | Ortalama IOPS (Okuma) | Ortalama Gecikme (ms) | Maliyet/GB (Göreli) | Kullanım Alanı |
|---|---|---|---|---|
| HDD (7.2K RPM) | 80-150 | 5-10 | Düşük | Arşiv, büyük dosyalar |
| HDD (10K RPM) | 120-200 | 3-6 | Orta-Düşük | Genel dosya sunucu |
| SAS SSD | 50.000-100.000 | 0.1-0.2 | Yüksek | Kurumsal VT, sanallaştırma |
| NVMe SSD | 300.000-1.000.000+ | 0.02-0.05 | Çok Yüksek | HPC, AI, ultra-kritik VT |
Kapasite Planlaması ve Geleceğe Yönelik Yaklaşım
Sunucu disk planlamasında kapasite, sadece bugünün ihtiyaçlarını karşılamakla kalmayıp, aynı zamanda gelecekteki büyümeyi de hesaba katan stratejik bir yaklaşımdır. Benim tecrübelerime göre, kapasiteyi doğru tahmin etmek ve belirli bir “büyüme tamponu” bırakmak, uzun vadede çok daha az maliyetli ve daha az operasyonel zorluk yaratır.
Bir sistemin disk kullanımını takip etmek için Grafana ve InfluxDB gibi araçlarla izleme altyapısı kurduğumuzda, kapasite trendlerini net bir şekilde görebiliyoruz. Örneğin, bir dosya sunucusunun aylık ortalama %2-3 oranında büyüdüğünü tespit ediyorsak, sunucuyu ilk konumlandırırken en az 2-3 yıllık bir büyüme payı ile donatmak önemlidir. Aksi takdirde, erken kapasite sorunları yaşanır ve genişletme maliyeti, ilk kurulumdaki ek maliyetten çok daha fazla olabilir.
Bir örnek üzerinden gidelim: Diyelim ki bir KOBİ’nin ERP sistemi için 2 TB kullanılabilir disk alanına ihtiyacı var ve yıllık ortalama %15 büyüme bekleniyor. Eğer RAID 10 kullanacaksak ve 2 TB kullanılabilir alan için 4x1TB disk gerekiyorsa (RAID 10’da kapasitenin yarısı), üç yıl sonra %15’lik büyüme ile yaklaşık 3 TB kullanılabilir alana ihtiyacımız olacak. Bu durumda, başlangıçta 4x2TB disk ile gidip 4 TB kullanılabilir alan sunarak, hem mevcut ihtiyacı karşılarız hem de 3-4 yıl boyunca rahat ederiz. Bu tür bir hesaplama, “yaklaşık” değerlerle de olsa, sunucunun yaşam döngüsü maliyetini önemli ölçüde etkiler.
# Linux'ta disk kullanımını kontrol etme örneği
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 200G 50G 140G 27% /
/dev/sdb1 1.8T 900G 800G 53% /mnt/data
/dev/sdc1 5.0T 3.0T 2.0T 60% /mnt/backupBu basit komut bile, mevcut disk kullanımını ve kalan boş alanı hızlıca görmemizi sağlar. Düzenli izleme ile bu verileri toplayıp trendleri analiz ederek gelecekteki kapasite ihtiyaçlarını daha doğru tahmin edebiliriz.
Firmware Disiplini ve Donanım Uyumluluğu
Lenovo sunucularda disk altyapısının sorunsuz ve performanslı çalışması için sadece doğru donanımı seçmek yeterli değildir. Firmware disiplini ve donanım uyumluluğu, benim için en az donanım seçimi kadar kritik bir konudur. Sahada karşılaştığımız birçok “garip” performans düşüşünün veya rastgele sistem kilitlenmelerinin arkasında güncel olmayan firmware veya sürücü uyumsuzlukları yatıyor.
Bir RAID kontrolcüsü, HBA (Host Bus Adapter) veya hatta disklerin kendi firmware’leri, üreticinin belirlediği güncel seviyede olmalıdır. Lenovo, bu konuda düzenli olarak firmware güncellemeleri yayınlar ve bu güncellemeler genellikle performansı artırır, bilinen hataları giderir ve yeni işletim sistemleri veya donanımlarla uyumluluğu sağlar. Bu güncellemelerin uygulanması, bir sunucunun yaşam döngüsü boyunca stabilitesini ve verimliliğini korumak için vazgeçilmezdir.
# VMware ESXi üzerinde RAID kontrolcü firmware versiyonunu kontrol etme örneği
# Bu komutlar, sunucu modeline ve RAID kontrolcü üreticisine göre değişebilir.
# Örnek: LSI tabanlı MegaRAID kontrolcüsü için
esxcli software vib list | grep lsi
# Ardından lsi_mr3 sürücüsü için versiyon kontrol edilebilir.
# Firmware versiyonu genellikle kontrolcünün BIOS'unda veya web arayüzünde bulunur.
# Lenovo XClarity Controller (XCC) üzerinden de bu bilgiler merkezi olarak izlenebilir.Eğer bir sunucuyu Windows Server veya Linux dağıtımı ile kullanıyorsak, RAID kontrolcü sürücülerinin işletim sistemi ile tam uyumlu ve güncel olduğundan emin olmalıyız. Eski veya yanlış sürücüler, disklere erişimde gecikmelere, veri bozulmalarına veya beklenmedik sistem çöküşlerine yol açabilir. Biz ITWISE’te, yeni bir sunucuyu devreye almadan önce her zaman Lenovo’nun destek sitesinden en güncel firmware ve sürücü paketlerini indirip uygulamayı bir standart haline getirmiş durumdayız. Bu, olası sorunları daha ortaya çıkmadan engellemenin en etkili yoludur.
Yedekleme ve Kurtarma Süreçleri İçin Disk Altyapısı
Disk altyapısı planlaması, sadece günlük operasyonel performansı değil, aynı zamanda felaket kurtarma (Disaster Recovery - DR) ve yedekleme süreçlerinin etkinliğini de doğrudan etkiler. Benim için, bir sunucunun depolama çözümünü tasarlarken, “Bu sistemden nasıl ve ne kadar sürede yedek alacağız?”, “Bir felaket anında verileri ne kadar sürede geri yükleyebiliriz?” soruları, anahtar sorulardandır. Acronis gibi çözümlerle çalışırken, disk altyapısının bu süreçlere olan etkisi çok belirgindir.
Yüksek performanslı bir disk altyapısı, yedekleme pencerelerimizi önemli ölçüde kısaltır. Özellikle büyük veri setlerine sahip veya 7/24 çalışması gereken sistemlerde, yedekleme işleminin mümkün olan en kısa sürede tamamlanması kritik önem taşır. Eğer kaynak diskler yavaşsa, yedekleme işlemi saatler sürebilir, bu da RPO (Recovery Point Objective) hedeflerimizi riske atar ve sunucu üzerindeki yükü artırır. Aynı şekilde, bir felaket sonrası veri geri yükleme (restore) işlemi de disk hızına bağlıdır. Hızlı depolama, RTO (Recovery Time Objective) hedeflerimize ulaşmamızı kolaylaştırır.
Örneğin, 1 TB boyutunda bir sunucunun tam imaj yedeğini almayı düşünelim. Eğer sunucu üzerinde 4xSAS SSD RAID 10 yapılandırması varsa, yedekleme işlemi tipik olarak 2-3 saat içinde tamamlanabilir. Ancak aynı sunucu 4xSATA HDD RAID 5 üzerinde çalışıyorsa, bu süre 5-6 saate kadar çıkabilir, hatta daha da uzun sürebilir. Bu fark, özellikle hafta içi mesai saatlerinde yedekleme yapılması gereken senaryolarda büyük bir operasyonel zorluk yaratır. Kurtarma anında da benzer bir etki görülür; hızlı diskler sayesinde sistemler çok daha çabuk ayağa kalkar.
Sonuç: Disk Planlaması, Sunucunun Kalbidir
Lenovo sunucu seçiminde CPU’ya odaklanmanın doğal bir eğilim olduğunu anlıyorum. Ancak benim ITWISE olarak edindiğim tecrübeler ve sahadaki pratik uygulamalarımız, sunucunun gerçek dünya performansını ve iş sürekliliğini belirleyen asıl faktörün kapsamlı ve doğru yapılmış bir disk altyapısı planlaması olduğunu gösteriyor. Bir sunucunun işlemcisi beyni ise, disk altyapısı kalbidir; ve kalp doğru çalışmadığında, beyin ne kadar güçlü olursa olsun tüm sistem aksar.