SAN Depolama Nedir? Storage Area Network Nasıl Çalışır?

SAN depolama nedir, ne işe yarar?

SAN depolama, sunuculara blok seviyesinde paylaşımlı disk alanı sunan ve yalnızca depolama trafiğine ayrılmış özel bir ağ yapısıdır. Açılımı Storage Area Network olan bu yapıda sunucu, ağ üzerindeki diski kendi yerel diski gibi görür. Böylece birden çok sunucu aynı merkezi depolama havuzunu kullanır.

Depolama alanındaki tarafsız sektör kuruluşu SNIA, SAN kavramını çevrim içi sözlüğünde temel amacı bilgisayar sistemleri ile depolama aygıtları arasında veri taşımak olan bir ağ diye tanımlar. Yani SAN, internet trafiğinin aktığı genel ağdan farklı bir iş görür. Ofis ağınız e-posta ve web trafiğini taşırken SAN yalnızca disk okuma ve yazma isteklerini taşır.

Bu yazıda SAN depolamanın NAS ve DAS ile farkını, bileşenlerini, protokollerini ve hosting dünyasındaki yerini anlatıyoruz. Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz; bu yüzden anlatımı SNIA, IETF ve dağıtım belgeleri gibi birincil kaynaklara dayandırıyoruz. Amacımız, web sitesi sahibinin hosting teklifini okurken neyi sorması gerektiğini netleştirmek.

Blok seviyesinde depolama ne demek?

Bir disk, verileri sabit büyüklükte bloklar halinde saklar. İşletim sistemi bu blokların üzerine kendi dosya sistemini kurar ve hangi dosyanın hangi blokta durduğunu kendisi takip eder. Blok seviyesinde erişimde sunucu, depolama sistemine "şu adresteki blokları oku" der; dosya adı, klasör ya da izin bilgisi bu konuşmanın parçası değildir.

Dosya seviyesinde erişimde ise durum farklıdır. Sunucu, karşıdaki sisteme "şu klasördeki şu dosyayı ver" der ve dosya sistemini karşı taraf yönetir. Örneğin ofisteki ortak klasör böyle çalışır. SNIA da SAN tek başına dosya soyutlaması sağlamaz, yalnızca bloklar üzerinde işlem sunar diye vurgular.

Bu ayrımın pratik sonucu önemlidir. Blok erişimi, veritabanı ve sanal makine diski gibi düşük gecikme ve tutarlı yazma bekleyen iş yükleri için uygundur. Çünkü işletim sistemi diski doğrudan biçimlendirir, kendi önbelleğini ve dosya sistemini kullanır. Öte yandan aynı blok aygıtını iki sunucunun aynı anda yazması, küme farkındalığı olan bir dosya sistemi yoksa veri bozulmasına yol açar.

SAN, NAS ve DAS arasındaki fark nedir?

Üç kavram da bir sunucuya disk alanı vermenin farklı yollarıdır. DAS (Direct Attached Storage) diski doğrudan sunucuya bağlar. NAS (Network Attached Storage) dosya seviyesinde paylaşımı ağ üzerinden sunar. SAN ise blok seviyesinde paylaşımı ayrı bir depolama ağı üzerinden yapar. Aşağıdaki tablo farkları özetliyor:

Tablodaki en kritik satır, dosya sistemini kimin yönettiğidir. NAS'ta birden çok istemci aynı dosyalara güvenle erişir, çünkü kilitleme ve izinleri NAS cihazı yönetir. SAN'da ise her LUN genellikle tek bir sunucuya ya da küme yazılımıyla koordine olan bir sunucu grubuna aittir. Bu yüzden ortak klasör ihtiyacı için NAS, sanal makine diski için SAN daha doğal bir eşleşmedir.

Kısacası soru "hangisi daha iyi" değil, "hangi iş yükü neye ihtiyaç duyar" sorusudur. Küçük bir kurumsal site için DAS çoğu zaman yeterlidir. Ancak onlarca sanal makinenin aynı havuzu paylaştığı bir altyapıda SAN depolama ciddi esneklik sağlar.

Bir SAN hangi bileşenlerden oluşur?

Bir SAN, birbirini tamamlayan birkaç katmandan oluşur. Her katmanın görevi farklıdır ve biri zayıf kaldığında bütün yapının performansı düşer. Temel bileşenler şunlardır:

• Depolama dizisi: Çok sayıda diski RAID ile bir araya getiren, üzerinde denetleyici ve önbellek bulunan merkezi cihaz.
• HBA veya ağ kartı: Sunucunun SAN ile konuşmasını sağlayan kart; Fibre Channel için HBA, iSCSI için genellikle Ethernet kartı.
• Anahtarlar: Sunucular ile depolama dizisi arasındaki trafiği yönlendiren, çoğu zaman yedekli kurulan ağ cihazları.
• Kablolama: Fiber optik ya da bakır bağlantılar; iyi bir tasarım genellikle iki bağımsız yol içerir.
• Yönetim yazılımı: Disk alanını bölen, erişim izni veren ve sağlık durumunu izleyen arayüz.

Bu listede dikkat çeken nokta, her katmanın en az ikişer kopya halinde düşünülmesidir. Çünkü SAN çöktüğünde ona bağlı tüm sunucular aynı anda diskini kaybeder. Bu nedenle ciddi kurulumlarda iki ayrı anahtar, iki ayrı kart ve iki ayrı denetleyici standart bir tasarım tercihidir.

Depolama dizisindeki disk düzeni hakkında daha fazla ayrıntı isterseniz RAID seviyeleri ve farkları rehberimize göz atabilirsiniz. SAN, RAID ile korunan bu disk havuzunu ağ üzerinden dağıtan katmandır.

Fibre Channel nasıl çalışır?

Fibre Channel, depolama trafiği için tasarlanmış, kendi kablolama, anahtar ve adresleme kuralları olan bir ağ teknolojisidir. Standartları INCITS bünyesindeki T11 teknik komitesi geliştirir. Adına rağmen bakır kablo üzerinde de çalışabilir; ancak veri merkezlerinde çoğunlukla fiber optik kullanırsınız.

Fibre Channel ağında her bağlantı noktasının benzersiz bir kimliği vardır. Bu kimliğe WWN (World Wide Name) denir ve Ethernet dünyasındaki MAC adresine benzer bir rol oynar. Anahtarlar bu kimlikleri kullanarak hangi sunucunun hangi depolama portuyla konuşabileceğini belirler.

Fibre Channel'ın güçlü yanı, depolama trafiğini genel ağdan tamamen ayırmasıdır. Böylece bir web sunucusundaki yoğun trafik, disk erişimini doğrudan yavaşlatmaz. Öte yandan bu ayrım bedelsiz değildir: ayrı kartlar, ayrı anahtarlar ve bu ağı bilen bir ekip gerekir. Dolayısıyla Fibre Channel daha çok büyük kurumların ve veri merkezlerinin tercih ettiği bir yoldur.

Fibre Channel ağlarını genellikle iki bağımsız yapı olarak kurarsınız; sektör bu yapılara A ağı ve B ağı adını verir. Her sunucuyu her iki ağa da ayrı bir kartla bağlarsınız. Böylece bir anahtarın bakımı ya da arızası sırasında diğer ağ trafiği taşımaya devam eder. Bu düzen, SAN tasarımında tek arıza noktasını ortadan kaldırmanın en bilinen yoludur.

iSCSI nedir, SAN depolama için neden yaygın?

iSCSI, SCSI disk komutlarını TCP/IP üzerinden taşıyan bir protokoldür. IETF'in RFC 7143 belgesi iSCSI'yi TCP üzerinde çalışan bir SCSI taşıma protokolü olarak tanımlar. Yani standart Ethernet altyapısıyla bir SAN kurmanızı sağlar.

iSCSI dünyasında iki rol vardır. Diski kullanan sunucuya initiator, diski sunan sisteme target dersiniz. Her iki taraf da iqn ile başlayan, alan adına dayalı benzersiz bir isim taşır. Hedef taraf, IANA kaydına göre standart olarak TCP 3260 portunu dinler.

iSCSI'nin yaygın olmasının nedeni maliyet ve tanıdıklıktır. Mevcut Ethernet bilgisi ve donanımıyla başlayabilirsiniz. Ancak iyi bir iSCSI kurulumu yine de depolama trafiğini ayrı bir VLAN ya da ayrı anahtarlar üzerinde tutar. Aksi halde yedekleme işi ya da ani bir trafik artışı, veritabanınızın disk gecikmesini yükseltir. Ayrıca kimlik doğrulama için CHAP gibi mekanizmaları açmanızı öneririz.

Ağ tarafında da birkaç temel ayara dikkat etmeniz gerekir. Örneğin depolama trafiği için ayrılmış kartlarda ve anahtarlarda tutarlı bir MTU değeri kullanın; uçtan uca eşleşmeyen bir ayar zor teşhis edilen yavaşlıklar doğurur. Ayrıca yönetim trafiğini ve depolama trafiğini aynı kartta toplamamaya çalışın.

FCoE ve diğer taşıma seçenekleri nelerdir?

FCoE (Fibre Channel over Ethernet), Fibre Channel çerçevelerini doğrudan Ethernet çerçevelerinin içine yerleştirir. Böylece Fibre Channel'ın yönetim modelini korurken tek bir Ethernet altyapısı kullanırsınız. Ancak FCoE kayıpsız Ethernet ister; bunun için anahtarların Data Center Bridging özelliklerini desteklemesi gerekir.

Son yıllarda NVMe over Fabrics da gündemde. Bu yaklaşım, NVMe komut setini ağ üzerinden taşır ve TCP, RDMA ya da Fibre Channel üzerinde çalışabilir. Spesifikasyonu NVM Express kuruluşu yayımlar. Özetle seçenekleri şöyle gruplayabilirsiniz:

• Fibre Channel: Ayrı ve olgun bir depolama ağı, yüksek yatırım.
• iSCSI: Ethernet ve TCP/IP üzerinde, başlangıç maliyeti daha düşük.
• FCoE: Fibre Channel mantığı, Ethernet kablolaması, kayıpsız ağ şartı.
• NVMe over Fabrics: Flash disklerin düşük gecikmesini ağ üzerine taşımayı hedefleyen yeni nesil yol.

Hangi protokolün hangi hızda çalıştığı donanım nesline ve yapılandırmaya göre değişir. Bu yüzden bir teklifte yalnızca protokol adını değil, yedekli yol sayısını ve ölçülmüş gecikme değerlerini de sormanız daha doğru olur.

LUN, zoning ve maskeleme ne anlama gelir?

SAN depolama dizisi, büyük disk havuzunu daha küçük mantıksal disklere böler. Her birine LUN (Logical Unit Number) dersiniz. Sunucu açısından bir LUN, takılı yeni bir disk gibi görünür; sunucu onu biçimlendirir ve üzerine dosya sistemi kurar.

Peki hangi sunucu hangi LUN'u görecek? Burada iki katmanlı bir erişim kontrolü devreye girer:

• Zoning: Fibre Channel anahtarında hangi portların birbirini görebileceğini belirler; ağ seviyesinde bir ayırmadır.
• LUN maskeleme: Depolama dizisinde hangi sunucunun hangi LUN'a erişebileceğini belirler.
• iSCSI erişim listeleri: iSCSI tarafında initiator ismine ve isteğe bağlı CHAP kimlik doğrulamasına göre izin verir.

Bu katmanlardan biri yanlış ayarlandığında iki farklı sunucu aynı diski kendi diski sanabilir. Örneğin iki ayrı Linux sunucusu aynı LUN'u standart bir dosya sistemiyle bağlarsa, birbirinin yazdığı veriyi bozar. Dolayısıyla SAN yönetimi, ağ yönetimi kadar dikkatli bir değişiklik disiplini ister.

Multipath neden önemlidir?

Multipath, bir sunucunun aynı LUN'a birden fazla fiziksel yoldan erişmesi demektir. Örneğin sunucuda iki kart, SAN tarafında iki anahtar ve dizide iki denetleyici varsa, aynı diske dört farklı yoldan ulaşabilirsiniz. Bir kablo koptuğunda trafik kalan yollardan devam eder.

Linux tarafında bu işi çoğunlukla DM Multipath üstlenir. Red Hat'in DM Multipath belgesi bu katmanın G/Ç yollarını toplayıp bunlardan oluşan yeni bir aygıt ürettiğini anlatır. Böylece uygulama tek bir disk görür, yol değişimini ise alttaki katman yönetir.

Multipath olmadan aynı LUN işletim sisteminde iki ya da dört ayrı disk gibi görünebilir. Bu durumda yanlış aygıtı biçimlendirmek ya da yalnızca bir yolu kullanmak gibi hatalar ortaya çıkar. Bu yüzden SAN bağlı her sunucuda multipath yapılandırması, kurulum listesinin zorunlu bir maddesi olmalı.

SAN depolamanın avantajları nelerdir?

SAN depolamanın en büyük getirisi, diski sunucudan ayırmasıdır. Disk artık belirli bir makinenin içinde değil, merkezi bir havuzdadır. Bu ayrım şu avantajları doğurur:

• Merkezi yönetim: Kapasiteyi tek noktadan izler, büyütür ve dağıtırsınız.
• Esnek kapasite: Bir sunucunun diski dolduğunda havuzdan ek alan ayırırsınız; çoğu zaman donanım değişikliği gerekmez.
• Canlı taşıma: Sanal makineyi bir fiziksel sunucudan diğerine, disk yerinde kalırken taşırsınız.
• Anlık görüntü: Depolama dizisi düzeyinde snapshot alır, güncelleme öncesi hızlı bir geri dönüş noktası oluşturursunuz.
• Yüksek erişilebilirlik: Bir sunucu arızalandığında aynı diski gören başka bir sunucu iş yükünü devralır.

Ayrıca depolama dizilerinin çoğu, verinin başka bir lokasyondaki diziye kopyalanması gibi replikasyon özellikleri sunar. Ancak bu özelliklerin varlığı, doğru yapılandırıldıkları anlamına gelmez. Bir hosting sağlayıcısı "SAN altyapısı" dediğinde, bu avantajlardan hangilerini gerçekten kullandığını sormanız gerekir.

SAN depolamanın dezavantajları ve riskleri nelerdir?

SAN güçlü bir yapıdır ama her senaryoya uygun değildir. İlk dezavantaj maliyettir. Depolama dizisi, yedekli anahtarlar, kartlar ve lisanslar ciddi bir yatırım gerektirir. Üstelik bu ekipmanı yönetecek, depolama ağını bilen bir ekibe ihtiyaç duyarsınız.

İkinci dezavantaj karmaşıklıktır. Zoning, LUN maskeleme, multipath ve firmware uyumluluğu gibi konular küçük bir ekibin günlük gündemine kolayca sığmaz. Yanlış bir değişiklik tek bir sunucuyu değil, havuzu paylaşan tüm sunucuları etkiler.

Üçüncü risk paylaşılan kaynaktır. Aynı dizi üzerinde çalışan bir sanal makine yoğun disk işlemi yaptığında, komşu makinelerin disk gecikmesi de artabilir. Bu yüzden iyi sağlayıcılar sanal makine başına disk işlem sınırı koyar. Disk performansını nasıl ölçeceğinizi IOPS ve disk performansı yazımızda anlattık. Son olarak SAN, ağ gecikmesini disk erişimine ekler; yerel NVMe diskle kıyaslandığında bu fark bazı iş yüklerinde hissedilir.

Sanallaştırma kümeleri neden paylaşımlı depolamaya ihtiyaç duyar?

Bir sanallaştırma kümesinde birkaç fiziksel sunucu, onlarca hatta yüzlerce sanal makineyi birlikte çalıştırır. Sanal makinenin diski fiziksel sunucunun içindeyse, o sunucu arızalandığında disk de erişilemez hale gelir. Paylaşımlı depolamada ise disk, kümedeki tüm sunucuların görebildiği ortak alandadır.

Bu yapı iki önemli işi kolaylaştırır. Birincisi canlı taşımadır: hipervizör sanal makinenin belleğini başka bir fiziksel sunucuya aktarır, disk ise yerinde kalır. İkincisi yüksek erişilebilirliktir: bir fiziksel sunucu durduğunda küme, sanal makineyi başka bir sunucuda yeniden başlatır.

Paylaşımlı depolama her zaman klasik bir SAN olmak zorunda değildir. NFS tabanlı NAS ya da sunucuların yerel disklerini ağ üzerinden birleştiren dağıtık depolama sistemleri de aynı ihtiyacı karşılar. Sanallaştırmanın temelini merak ediyorsanız KVM sanallaştırma rehberimiz iyi bir başlangıç noktasıdır.

VPS diskiniz bir SAN üzerinde olabilir mi?

Evet, olabilir. Bir VPS satın aldığınızda sanal makinenizin diski üç yerden birinde durur: fiziksel sunucunun yerel diskinde, ağ üzerinden bağlanan bir SAN ya da NAS üzerinde veya dağıtık bir depolama kümesinde. Sağlayıcı bu tercihi çoğu zaman paket açıklamasına açıkça yazmaz.

Bu tercih size birkaç ipucuyla yansır. Örneğin sağlayıcı, fiziksel sunucu arızasında VPS'inizi dakikalar içinde başka bir makinede ayağa kaldırıyorsa büyük olasılıkla paylaşımlı depolama kullanır. Öte yandan "yerel NVMe" vurgusu yapan paketler genellikle diski fiziksel sunucunun içinde tutar; bu durumda gecikme düşer ama donanım arızasında taşıma daha zordur.

Hangi modelin size uygun olduğunu anlamak için VPS, VDS ve bulut sunucu farkı yazımızdaki karar ölçütlerine bakabilirsiniz. Sitenizin hangi sağlayıcıda ve hangi IP bloğunda durduğunu merak ediyorsanız IP sorgulama aracımızı kullanabilirsiniz.

Bir SAN arızası web sitesini nasıl etkiler?

SAN, iyi tasarlandığında tek bir parçanın arızasını tolere eder. Ancak tasarımdaki bir boşluk ya da aynı anda birden fazla bileşeni etkileyen bir hata, havuzu kullanan tüm sunucuları birlikte etkiler. Bu yüzden SAN kaynaklı sorunlar genellikle tek bir sitede değil, aynı altyapıdaki pek çok sitede aynı anda ortaya çıkar.

Belirtiler çoğu zaman tam bir kesintiyle başlamaz. Önce disk gecikmesi artar, veritabanı sorguları uzar ve sayfa yanıt süreleri yükselir. Ardından bazı istekler zaman aşımına düşer. En kötü senaryoda işletim sistemi diski kaybettiğini düşünür ve dosya sistemini salt okunur moda alır; bu durumda site yeni sipariş ya da form kaydı yazamaz.

Bir site sahibi olarak bu tabloyu tek başınıza çözemezsiniz; ancak doğru veriyi toplayabilirsiniz. Örneğin sorunun başladığı saati, etkilenen sayfaları ve hata mesajlarını not edin. Ayrıca sağlayıcının durum sayfasını kontrol edin. Böylece destek ekibine "site yavaş" yerine ölçülebilir bir tablo sunarsınız ve çözüm süresi kısalır.

Kurumsal bir SAN projesi nereden başlar?

Kendi altyapısını kuran bir kurumsanız, SAN kararı donanım kataloğuyla değil, iş yükü analiziyle başlamalı. Önce hangi uygulamanın ne kadar kapasite, ne kadar disk işlemi ve ne kadar gecikme toleransı istediğini çıkarırsınız. Ardından bu ihtiyaçları karşılayan en sade mimariyi ararsınız.

Pratikte izlenen sıra şöyledir:

1. Mevcut sunucuların disk kullanımını, okuma ve yazma oranını, en yoğun saatlerdeki disk işlem sayısını ölçün.
2. Kesinti toleransını iş birimleriyle birlikte belirleyin; hangi sistem kaç dakika durabilir sorusunu cevaplayın.
3. Ekibinizin bildiği teknolojiyi tercih edin; Ethernet bilgisi güçlüyse iSCSI, mevcut Fibre Channel yatırımı varsa onu değerlendirin.
4. Yedekli yol, yedekli denetleyici ve ayrı yedekleme hedefini baştan tasarıma ekleyin.
5. Canlıya geçmeden önce yol kesme, denetleyici değişimi ve geri yükleme testlerini yapın.

Bu süreç, yanlış boyutlandırılmış pahalı bir dizinin ya da yetersiz bir ağın yıllarca sorun çıkarmasını önler. Kısacası SAN projesinin başarısı, satın alma gününden çok önce aldığınız ölçümlere bağlıdır.

Bütçe planında yalnızca ilk yatırımı değil, işletme giderini de hesaba katın. Bakım sözleşmesi, yedek parça, lisans yenilemesi ve ekibin eğitim süresi, birkaç yıllık toplam maliyetin önemli bir bölümünü oluşturur. Bu nedenle aynı ihtiyacı bulut sağlayıcının yönetilen blok depolama hizmetiyle karşılamanın maliyetini de karşılaştırmanızı öneririz.

SAN, RAID ve yedeğin yerini tutar mı?

Hayır, SAN depolama ne RAID'in ne de yedeğin yerini tutar. RAID, disk arızasına karşı depolama dizisinin içindeki diskleri korur. SAN ise bu korunan havuzu ağ üzerinden sunuculara dağıtır. İkisi farklı katmanlarda çalışır ve birbirini tamamlar.

Yedek ise bambaşka bir sorunun cevabıdır. Yanlışlıkla silinen bir tablo, fidye yazılımı ya da hatalı bir güncelleme, SAN üzerindeki veriyi de anında etkiler. Çünkü SAN, yazdığınız her değişikliği sadakatle saklar. Anlık görüntü bu konuda yardımcı olur ama aynı dizi üzerinde durduğu sürece dizinin kendisi arızalandığında işe yaramaz.

Bu nedenle sağlam bir plan şu üç katmanı birlikte içerir:

• Depolama dizisinde RAID ile disk arızasına karşı koruma.
• Snapshot ile kısa vadeli, hızlı geri dönüş noktası.
• Farklı bir sistemde ve tercihen farklı bir lokasyonda tutulan, geri yükleme testi yapılmış yedek.

Yedek tarafının ayrıntıları için web sitesi yedekleme stratejisi yazımızı okuyabilirsiniz.

Linux sunucuda iSCSI diski nasıl görürsünüz?

Kendi sunucusunu yöneten okurlar için kısa bir örnek verelim. Aşağıdaki adımlar Red Hat'in iSCSI initiator belgesine dayanır ve RHEL ailesindeki dağıtımlar içindir. Örnekteki IP adresi ve isim yalnızca dokümantasyon amaçlıdır.

# Initiator paketini kurun (RHEL ailesi)
dnf install iscsi-initiator-utils

# Sunucunun iSCSI ismini görün
cat /etc/iscsi/initiatorname.iscsi

# Hedef sistemdeki diskleri keşfedin
iscsiadm -m discovery -t st -p 192.0.2.10

# Keşfedilen hedefe oturum açın
iscsiadm -m node -T iqn.2005-01.com.example:depo1 -l

# Yeni blok aygıtını listeleyin
lsblk

# Multipath kullanıyorsanız yolları görün
multipath -ll

Bu komutları çalıştırmadan önce dikkat etmeniz gereken noktalar şunlardır:

1. Depolama tarafında sunucunuzun initiator ismine erişim izni verilmiş olmalı.
2. Yeni aygıtı biçimlendirmeden önce lsblk çıktısını iki kez kontrol edin; yanlış diski biçimlendirmek geri dönüşü olmayan bir hatadır.
3. Birden fazla yol varsa diski multipath aygıtı üzerinden bağlayın, tekil yolu kullanmayın.
4. Debian ve Ubuntu ailesinde paket adı ve servis adları farklıdır; dağıtımınızın kendi belgesine bakın.

Hangi durumda bu işi hosting sağlayıcısına bırakmalısınız?

Dürüst olmak gerekirse, web sitesi sahiplerinin büyük çoğunluğu için SAN kurmak ya da yönetmek doğru bir iş değildir. Paylaşımlı hosting, yönetilen VPS ya da bulut sunucu kullanıyorsanız depolama katmanı zaten sağlayıcının sorumluluğundadır. Sizin işiniz, o katmanın nasıl çalıştığını sorgulamak ve sonucunu ölçmektir.

Şu durumlarda işi sağlayıcıya bırakmanızı öneririz:

• Ekibinizde Fibre Channel, iSCSI ve multipath deneyimi olan bir sistem yöneticisi yoksa.
• İş yükünüz tek bir sunucuya sığıyorsa ve yüksek erişilebilirlik kümesine gerçekten ihtiyaç duymuyorsanız.
• Depolama donanımı için ayrı bir bütçe ve bakım sözleşmesi ayıramıyorsanız.
• Sorun anında saatler içinde müdahale edecek bir nöbet düzeniniz yoksa.

Kendi SAN altyapısını kurmak daha çok kendi veri merkezini ya da sanallaştırma kümesini işleten kurumların konusudur. Maliyet tarafını değerlendirmek isterseniz sunucu kiralama maliyetini etkileyen etkenler yazımız iyi bir çerçeve sunar.

Web sitesi sahibi için SAN depolamanın pratik anlamı nedir?

Bir web sitesi sahibi olarak SAN depolama ile doğrudan muhatap olmazsınız; ancak sonuçlarını her gün yaşarsınız. Sayfa yüklenirken veritabanı sorgusu diske gider. Bu diskin yerel mi, ağ üzerinden mi olduğu ve ne kadar yoğun paylaşıldığı, sorgunun ne kadar hızlı döndüğünü etkiler.

Örneğin bir e-ticaret sitesinde kampanya günü trafik artar, site sipariş tablosuna sık sık yazar. Depolama katmanı zorlanırsa sayfalar yavaşlar ve ödeme adımları uzar. Sitenizin neden yavaşladığını teşhis etmek için sunucu kaynaklı yavaşlık nedenleri yazımızdaki sırayı izleyebilirsiniz.

Öte yandan SAN, kesinti süresini azaltan bir yapı da olabilir. Fiziksel sunucu arızasında sanal makinenizin başka bir sunucuda hızla açılması, ziyaretçinin fark etmeyeceği kadar kısa bir kesinti anlamına gelir. Biz de web tasarım ve e-ticaret danışmanlığı projelerinde altyapı seçimini bu iki açıdan, yani hız ve süreklilik açısından değerlendiriyoruz.

Hosting teklifinde depolama hakkında hangi soruları sormalısınız?

Teklif metinleri genellikle disk boyutunu ve "SSD" ya da "NVMe" ibaresini öne çıkarır. Ancak depolama kalitesini anlamak için birkaç soru daha sormanız gerekir:

1. Sanal makinemin diski yerel diskte mi, ağ üzerinden bağlanan paylaşımlı depolamada mı duruyor?
2. Depolama katmanında yedekli yol ve yedekli denetleyici var mı?
3. Sanal makine başına disk işlem ya da bant genişliği sınırı uyguluyor musunuz?
4. Fiziksel sunucu arızasında sanal makinem otomatik olarak başka bir sunucuda açılıyor mu?
5. Snapshot ve yedekler aynı depolama dizisinde mi, ayrı bir sistemde mi tutuluyor?
6. Yedekten geri yükleme ne kadar sürüyor ve bunu en son ne zaman test ettiniz?

Bu soruların cevapları, iki benzer fiyatlı paket arasındaki gerçek farkı ortaya çıkarır. Disk ile ağ arasındaki ilişkiyi daha iyi anlamak için bant genişliği rehberimize de bakabilirsiniz. Genel seçim ölçütleri için ise hosting seçim rehberimiz size kontrol listesi sunar.

Sonuç: SAN depolama kimin için doğru tercih?

SAN depolama, diski sunucudan ayırarak merkezi yönetim, canlı taşıma ve yüksek erişilebilirlik sağlar. Bu nedenle sanallaştırma kümeleri, büyük veritabanları ve kesintiye toleransı düşük kurumsal sistemler için güçlü bir yapıdır. Ancak maliyeti, karmaşıklığı ve uzmanlık ihtiyacı, onu küçük projeler için gereksiz kılar.

Bir web sitesi ya da e-ticaret sahibi olarak sizin için doğru soru, SAN kurup kurmamak değil, sağlayıcınızın depolama katmanını nasıl tasarladığıdır. Yukarıdaki soruları sorun, cevapları yazılı alın ve sitenizin gerçek performansını ölçün. Böylece "SSD disk" gibi genel ifadelerin ötesinde, verinizin nerede ve nasıl korunduğunu bilerek karar verirsiniz.