Azure Local Storage Spaces Direct ve Veri Dayanıklılığı

Azure Local projelerinde storage tarafında en sık gördüğüm yanlışlardan biri, kapasite hesabının sunucular üzerindeki disklerin toplamı üzerinden yapılması. Dört sunucuda toplam 100 TB disk varsa 100 TB kullanılabilir alanımız olduğu düşünülüyor. Halbuki Storage Spaces Direct tarafında disklerin fiziksel kapasitesi, VM’lerin kullanabileceği kapasite ve bir arıza sonrasında sistemin kendisini onarabilmesi için ihtiyaç duyduğu kapasite birbirinden farklı kavramlar.

Bir önceki makalede network tarafını incelerken Storage Spaces Direct trafiğinin neden önemli olduğunu anlatmıştım. SMB Direct, RDMA ve SMB Multichannel aslında storage mimarisinin network tarafındaki parçalarıydı. Bu kez network’ün diğer tarafına geçip verinin Azure Local içerisinde nasıl tutulduğuna, disk veya node kaybettiğimizde ne olduğuna ve doğru resiliency modelini nasıl seçmemiz gerektiğine bakalım.

Azure Local’ın hyperconverged mimarisinde storage katmanının temelinde Storage Spaces Direct bulunuyor. Her fiziksel sunucudaki lokal diskler yazılım tanımlı ortak bir storage pool içerisinde bir araya getiriliyor. Bu pool üzerinde oluşturulan volume’lar ise Cluster Shared Volume olarak bütün cluster node’ları tarafından erişilebilir hale geliyor. Hyper-V VM’lerinin VHDX dosyaları gibi workload verilerini bu volume’lar üzerinde tutuyoruz. Microsoft da güncel dokümantasyonunda Storage Spaces Direct’ı Azure Local’ın temel software-defined storage teknolojisi olarak tanımlıyor.

Burada klasik SAN mimarisinden önemli bir fark var.

SAN kullandığımız yapıda storage controller ve diskler ayrı bir sistem oluştururken Azure Local hyperconverged yapıda storage fiziksel sunucuların kendisinin bir parçası. Bu nedenle sadece disk arızasını değil, sunucunun tamamının kaybedilmesini de storage tasarımının içinde düşünmek gerekiyor.

Storage Spaces Direct’ın resiliency modeli de tam olarak bunun üzerine kurulmuş durumda.

Fiziksel diskten VM’nin gördüğü alana kadar ne oluyor?

Basit bir örnek üzerinden gidelim.

Dört Azure Local node’umuz olsun. Her node üzerinde 10 adet 3,84 TB NVMe capacity drive bulunduğunu düşünelim.

Kağıt üzerinde:

4 node x 10 disk x 3,84 TB = 153,6 TB raw capacity

İlk bakışta 153,6 TB storage’ımız var.

Ancak bu sadece fiziksel kapasite.

Storage Spaces Direct diskleri pool içerisinde birleştiriyor, ardından bu pool üzerinde oluşturduğumuz volume’un resiliency modeline göre verinin birden fazla kopyasını farklı fiziksel fault domain’lere dağıtıyor.

Eğer three-way mirror kullanıyorsak 1 TB veriyi saklamak için yaklaşık 3 TB fiziksel kapasite gerekiyor. Microsoft’un tanımıyla three-way mirror storage efficiency yüzde 33,3.

Dolayısıyla 153,6 TB raw capacity gördüğünüz bir sistemde:

153,6 TB / 3 ≈ 51,2 TB

teorik olarak three-way mirror kullanılabilir kapasitesine yaklaşıyoruz.

Ama burada bile hesabımız bitmedi.

Çünkü pool’un tamamını volume’lara vermememiz gerekiyor.

Repair için reserve capacity bırakacağız.

File system overhead olacak.

Gelecekteki büyümeyi düşüneceğiz.

Yani satın aldığımız 153,6 TB fiziksel disk kapasitesini müşteriye “153 TB usable storage” olarak anlatmak ciddi bir tasarım hatası olur.

Bu yüzden Azure Local sizing yaparken ben her zaman üç rakamı ayrı ayrı konuşmayı tercih ediyorum:

Raw capacity, usable capacity ve operational free capacity.

Üçü aynı şey değil.

Mirror neden bu kadar fazla kapasite tüketiyor?

Storage Spaces Direct iki temel resiliency yaklaşımı kullanıyor: mirroring ve parity.

Mirroring’in çalışma mantığı oldukça basit. Verinin birden fazla tam kopyası farklı fiziksel fault domain’lerde tutuluyor.

Two-way mirror her verinin iki kopyasını tutuyor. Bu nedenle storage efficiency yüzde 50. 1 TB veri için 2 TB fiziksel kapasite gerekiyor.

Three-way mirror ise verinin üç kopyasını tutuyor. Storage efficiency yüzde 33,3. 1 TB veri için 3 TB fiziksel kapasite gerekiyor.

İlk bakışta yüzde 33 storage efficiency kötü görünebilir.

Ama karşılığında ciddi bir fault tolerance elde ediyoruz.

Microsoft’un güncel dokümantasyonuna göre three-way mirror iki farklı hardware fault domain’in aynı anda etkilenmesine rağmen veriyi online tutabiliyor. Örneğin bir node maintenance nedeniyle kapalıyken başka bir node veya disk arızalanırsa veri erişilebilir kalabiliyor.

İşte bu nedenle üç veya daha fazla node’lu production Azure Local ortamlarında three-way mirror benim ilk bakacağım seçenek olur.

Microsoft’un Azure Local Well-Architected Framework dokümanındaki güncel önerisi de üç veya daha fazla node kullanan standart hyperconverged all-flash deployment’larda performans ve resiliency için three-way mirrored volume kullanılması yönünde.

Burada önemli olan “üç kopya daha güvenli” demekten ziyade hangi arıza senaryosunu çözmeye çalıştığımızı anlamak.

Bir Azure Local node’una update yapıyorsunuz.

Node maintenance modunda ve cluster dışında.

Tam o sırada başka bir node üzerindeki NVMe disklerden biri arızalandı.

Storage mimarisini sadece tek arızaya göre tasarladıysanız maintenance window sırasında ikinci problem geldiğinde artık gerçek bir availability problemi yaşayabilirsiniz.

Three-way mirror’ın değeri tam olarak böyle zamanlarda ortaya çıkıyor.

Normal çalışan sistemde resiliency’nin ne kadar iyi olduğunu anlamak zor.

Asıl test sistem zaten degraded durumdayken ikinci problemin gelmesi.

Parity neden var?

Mirror’ın dezavantajı çok açık: kapasite maliyeti.

100 TB gerçek veri saklamak için three-way mirror ile yaklaşık 300 TB fiziksel kapasite kullanmak her workload için ekonomik olmayabilir.

Özellikle yüksek kapasiteli ancak sürekli yüksek write IOPS gerektirmeyen workload’larda parity daha anlamlı hale gelebiliyor.

Storage Spaces Direct single parity ve dual parity destekliyor. Ancak Microsoft single parity kullanımını tavsiye etmiyor. Bunun nedeni single parity’nin aynı anda yalnızca tek hardware failure’ı güvenli şekilde tolere edebilmesi. Üç node’lu bir yapıda Microsoft three-way mirror kullanılmasını öneriyor.

Dört veya daha fazla node olduğunda ise dual parity kullanabiliyoruz.

Dual parity’yi klasik storage dünyasındaki RAID-6’ya benzetebiliriz. Storage Spaces Direct burada Reed-Solomon error correction ve daha büyük ölçeklerde Microsoft Research tarafından geliştirilen Local Reconstruction Codes kullanıyor.

Dört node’lu bir yapıda dual parity storage efficiency yüzde 50.

Yani 2 TB veri için 4 TB fiziksel kapasite gerekiyor.

Node sayısı arttıkça verimlilik de yükseliyor. Yedi node’da yüzde 66,7 seviyesine çıkıyor ve daha büyük yapılarda yüzde 80’e kadar ulaşabiliyor.

Three-way mirror ile karşılaştırdığınızda kapasite avantajı oldukça büyük.

Ama ücretsiz değil.

Parity hesaplaması mirror’a göre daha fazla compute işlemi gerektiriyor ve özellikle write ağırlıklı workload’larda performans tarafında mirror kadar avantajlı değil. Microsoft da performansa duyarlı workload’ların çoğu için mirroring kullanılmasını öneriyor.

Bu nedenle “parity daha fazla usable capacity veriyor, bütün volume’ları parity yapalım” doğru bir yaklaşım değil.

Storage tasarımında kapasite ve performans arasında seçim yapıyoruz.

SQL Server veya yoğun transaction üreten bir workload ile büyük miktarda daha az aktif verinin tutulduğu bir workload’un aynı resiliency modelinde olması gerekmiyor.

Mirror-accelerated parity burada devreye giriyor

Storage Spaces Direct’ın güzel taraflarından biri volume seviyesinde tek bir resiliency modeline mahkum olmamamız.

Mirror-accelerated parity ile aynı volume içerisinde mirror ve parity katmanlarını beraber kullanabiliyoruz.

Mantık basit.

Yoğun ve latency-sensitive write işlemleri mirror katmanından faydalanırken daha capacity-oriented veri parity katmanında tutulabiliyor.

Microsoft bu modeli mirror performansı ile parity’nin kapasite verimliliği arasında denge kurulması gereken workload’lar için sunuyor.

Ancak burada yine otomatik olarak “en iyi seçenek budur” sonucuna gitmemek gerekiyor.

Mimari karmaşıklaştıkça sizing de daha önemli hale geliyor. Workload’un gerçekten ne kadar write yaptığı, aktif data set’in büyüklüğü ve kapasite beklentisi bilinmeden mirror/parity oranını belirlemek doğru olmaz.

Ben genel amaçlı sanallaştırma altyapısında, özellikle all-flash Azure Local sistemlerinde Microsoft’un önerdiği three-way mirror ile başlayıp ancak kapasite ihtiyacı gerçek bir gerekçe oluşturuyorsa parity veya mirror-accelerated parity değerlendirmeyi daha doğru buluyorum.

Çünkü storage maliyetinden tasarruf ederken workload performansını kaybetmenin pek anlamı yok.

İki node’lu Azure Local biraz farklı

İki node’lu Azure Local sistemleri özellikle şube, küçük üretim tesisi veya edge senaryolarında oldukça mantıklı olabiliyor.

Ama iki node olduğunda fiziksel fault domain sayımız da iki.

Dolayısıyla klasik three-way mirror kullanamıyoruz.

Temel seçenek two-way mirror.

Two-way mirror verinin iki kopyasını iki node arasında tutuyor ve yüzde 50 storage efficiency sağlıyor. Fakat burada doğal bir problem var.

Node’lardan biri kapalıyken diğer node üzerinde bir disk daha kaybederseniz elimizde üçüncü bir kopya yok.

İşte nested resiliency bu problem için geliştirildi.

Microsoft’un nested resiliency özelliği iki node’lu Storage Spaces Direct cluster’ın aynı anda birden fazla hardware failure’a dayanabilmesini sağlıyor. Amaç, bir node kaybı ile diğer node üzerindeki disk arızasının aynı anda yaşandığı senaryoda storage availability’yi korumak.

Nested two-way mirror ve nested mirror-accelerated parity seçenekleri bulunuyor.

Microsoft Azure Local Well-Architected Framework de iki node’lu ve node arızasıyla beraber disk arızasında online kalması gereken workload volume’ları için performans önceliğinde nested two-way mirror, kapasite verimliliği önceliğinde nested mirror-accelerated parity değerlendirilmesini öneriyor.

Burada yine kapasite maliyeti var.

Daha fazla fault tolerance istiyorsanız bunun fiziksel disk karşılığını ödüyorsunuz.

Storage dünyasında bedava resiliency yok.

Bu nedenle iki node’lu Azure Local tasarımında sadece “iki sunucu yeterli” diye düşünmemek gerekiyor. Workload’un kabul edebileceği failure modelini baştan belirlemek lazım.

Disk tipleri ve cache katmanı

Storage Spaces Direct tarafında performansı etkileyen bir diğer konu storage pool cache.

Azure Local, NVMe, SSD ve HDD tabanlı farklı disk kombinasyonlarını destekliyor. Ancak tamamen HDD’den oluşan deployment desteklenmiyor. Tek node konfigürasyonunda ise hybrid yapı desteklenmiyor; flat all-NVMe veya all-SSD gerekiyor.

Birden fazla disk tipi kullanıldığında Storage Spaces Direct en hızlı disk tipini otomatik olarak cache olarak seçiyor.

Örneğin:

NVMe + SSD  → NVMe cache, SSD capacity
NVMe + HDD  → NVMe cache, HDD capacity
SSD + HDD   → SSD cache, HDD capacity

NVMe + SSD + HDD bulunan bir yapıda ise NVMe cache görevi görüyor, SSD ve HDD capacity olarak kullanılabiliyor.

Burada kapasite hesabında çok önemli bir detay var.

Cache diskleri usable capacity’ye dahil edilmiyor.

Örneğin sunucuda iki adet 3,2 TB NVMe cache ve sekiz adet 7,68 TB SSD capacity drive varsa toplam fiziksel disk kapasitesini toplayıp usable alan hesabı yapamazsınız.

Cache diskleri storage pool’un kapasitesine katkı sağlamıyor. Kullanılabilir raw capacity yalnızca capacity drive’lardan geliyor.

Bu da Azure Local sizing sırasında sık yapılan hatalardan biri.

Bir diğer güzel detay cache davranışının disk tipine göre otomatik belirlenmesi.

NVMe’nin SSD’yi cache’lediği all-flash senaryoda sadece write cache kullanılıyor. Bunun önemli nedenlerinden biri capacity SSD’lerdeki write amplification ve endurance etkisini azaltmak.

HDD kullanılan hybrid yapıda ise hem read hem write cache devreye giriyor. Random write’lar cache üzerinde birleştirilip daha düzenli şekilde HDD’lere destage ediliyor.

Microsoft çoğu deployment için bu davranışın manuel değiştirilmesini önermiyor.

Bence burada da aynı prensip geçerli: gerçekten ölçülmüş bir ihtiyaç yoksa Storage Spaces Direct’ın validated default davranışını değiştirmeyin.

ReFS neden önemli?

Storage Spaces Direct üzerinde volume oluştururken Microsoft’un önerdiği file system ReFS.

ReFS özellikle virtualization workload’ları için tasarlanmış durumda ve block cloning gibi özelliklerle Hyper-V operasyonlarında ciddi avantajlar sağlayabiliyor. Ayrıca veri bozulmalarına karşı built-in koruma mekanizmaları bulunuyor. Microsoft Azure Local ve Storage Spaces Direct volume’ları için ReFS kullanımını öneriyor; workload’un ReFS’in desteklemediği bir özelliğe ihtiyacı varsa NTFS de kullanılabiliyor. Aynı cluster içerisinde ReFS ve NTFS volume’lar beraber bulunabiliyor.

Volume sayısı tarafında da bazı tasarım sınırları var.

Microsoft en az node başına bir volume oluşturulmasını öneriyor. Bunun nedeni CSV ownership ve metadata işlemlerinin node’lar arasında dengeli dağıtılabilmesi.

Cluster başına toplam volume sayısının ise 64 ile sınırlandırılması öneriliyor. Azure Local’da tek bir volume için önerilen üst sınır 64 TB.

Burada “500 TB storage var, tek bir 500 TB CSV açalım” yaklaşımının neden doğru olmadığını görebiliyoruz.

Volume tasarımı da kapasite planlamasının bir parçası.

Özellikle backup ürününüz VSS ve Volsnap kullanıyorsa Microsoft volume boyutunu 10 TB ile sınırlandırmanın performans ve güvenilirlik açısından faydalı olabileceğini belirtiyor. Hyper-V RCT, ReFS block cloning veya native SQL backup API kullanan modern çözümler ise 32 TB ve üzerindeki volume’larda daha iyi çalışabiliyor.

Yani backup mimarisi bile CSV boyutunu etkileyebilir.

En kritik konulardan biri reserve capacity

Bence Azure Local storage tasarımında en fazla atlanan konulardan biri bu.

Storage pool’daki bütün alanı volume’lara dağıtmamak gerekiyor.

Storage Spaces Direct bir disk arızalandığında veriyi kalan sağlıklı disklere yeniden dağıtıp resiliency seviyesini tekrar sağlamak istiyor. Bunun için pool içerisinde boş alan lazım.

Microsoft bu nedenle storage pool içerisinde sunucu başına bir capacity drive eşdeğeri, maksimum dört drive’a kadar reserve capacity bırakılmasını öneriyor.

Örneğin dört node’lu sistemde capacity drive’larınız 7,68 TB ise:

4 x 7,68 TB = 30,72 TB

seviyesinde kapasiteyi repair işlemleri için ayırmayı planlamanız gerekiyor.

Bu fiziksel olarak rafta bekleyen dört spare disk anlamına gelmiyor.

Pool içerisinde volume’lara tahsis edilmemiş kapasiteden bahsediyoruz.

Aradaki fark önemli.

Yeterli reserve capacity varsa bir disk arızalandığında Storage Spaces Direct failed drive’ın değiştirilmesini beklemeden veriyi kalan diskler üzerinde paralel şekilde repair ederek volume’u tekrar full resiliency durumuna getirebiliyor. Bu işlem otomatik gerçekleşiyor.

Bence bunun operasyonel değeri çok büyük.

Gece saat 03:00’te bir NVMe disk arızalandı.

Datacenter başka şehirde.

Yedek disk ertesi gün değiştirilecek.

Eğer yeterli reserve capacity bıraktıysanız cluster repair işlemini hemen başlatabiliyor. Teknik ekip fiziksel diski değiştirene kadar sistem degraded durumda beklemek zorunda değil.

Ama storage pool’u yüzde 98 doldurduysanız sistemin hareket edecek alanını kendiniz ortadan kaldırmış oluyorsunuz.

İşte bu nedenle “boş storage israf” değil.

Azure Local’da boş storage’ın bir kısmı resiliency’nin parçası.

Disk arızalandığında gerçekte ne oluyor?

Storage Spaces Direct fiziksel disk health durumunu sürekli takip ediyor.

Bir capacity drive arızalandığında sistem diski otomatik olarak retire ediyor ve üzerindeki veriyi sağlıklı diskler üzerine evacuate etmeye çalışıyor. Microsoft’un güncel disk replacement dokümantasyonunda failed drive’ın Retired durumuna geçtiği ve storage capacity bar’ının boşaldığı belirtiliyor.

Eğer yeterli kapasite varsa repair otomatik gerçekleşiyor.

Burada klasik RAID controller mantığından farklı bir operasyon görüyoruz.

Belirli bir hot spare disk bütün gün hiçbir iş yapmadan arıza beklemiyor. Boş kapasite pool geneline dağıtılmış durumda ve gerektiğinde repair için kullanılabiliyor.

Bunun iki avantajı var.

Birincisi spare capacity bütün disklerden faydalanabiliyor.

İkincisi repair işlemi tek bir replacement disk’in performansına bağlı kalmadan paralel gerçekleştirilebiliyor.

Ama bunun çalışması için baştan reserve capacity bırakmış olmanız gerekiyor.

Bu nedenle Azure Local monitoring tarafında sadece “disk healthy mi?” diye bakmak yeterli değil.

Pool free capacity de bir health metriği.

Cache diskini kaybedersek ne oluyor?

Cache drive failure biraz daha farklı.

Storage Spaces Direct cache server-local çalışıyor. Bir cache drive, aynı fiziksel sunucudaki bir veya daha fazla capacity drive’a bağlı olabiliyor.

Cache diskinde henüz capacity drive’a destage edilmemiş write’lar varsa cache diskini kaybettiğinizde bu lokal kopya kayboluyor.

Ama resiliency sayesinde aynı verinin diğer Azure Local node’larında başka kopyaları bulunuyor.

Storage Spaces Direct surviving copy’leri kullanarak veriyi otomatik repair ediyor ve capacity drive’ları başka cache drive’lara yeniden bağlıyor. Microsoft bu işlemin otomatik gerçekleştiğini belirtiyor.

Burada dikkat çekici bir başka Microsoft önerisi var:

Performansı korumak için node başına en az iki cache drive.

Tek cache drive kullanıp o diski kaybettiğinizde sadece resiliency değil, node üzerindeki storage performans modeli de ciddi şekilde değişebilir.

Bu yüzden storage tasarımında disk sayısına sadece capacity açısından bakmamak gerekiyor.

Disklerin rolü de önemli.

CSV cache ile storage pool cache aynı şey değil

Bu iki kavram zaman zaman karıştırılıyor.

Storage pool cache fiziksel storage katmanında çalışan persistent cache.

CSV in-memory read cache ise sistem RAM’inin bir bölümünü read cache olarak kullanıyor.

Azure Local’da CSV in-memory cache varsayılan olarak açık ve özellikle Hyper-V gibi unbuffered I/O kullanan workload’larda sık okunan verinin host memory’sinden karşılanmasını sağlayabiliyor. Böylece read işleminin storage network üzerinden diğer node’a gitme ihtiyacı azalıyor.

Özellikle VDI gibi read-intensive workload’larda faydalı olabilir.

Ama yine her workload için daha fazla cache daha iyi anlamına gelmiyor.

Microsoft çok write-intensive workload’larda CSV cache’in faydadan çok overhead oluşturabileceğini belirtiyor. Ayrıca cache için fiziksel RAM’in yüzde 80’ine kadar kullanım teknik olarak mümkün olsa da VM’ler için yeterli memory bırakılması gerektiğinin altını çiziyor.

Burada yine ölçmeden optimizasyon yapmamak gerekiyor.

Storage performansı düşük diye hemen cache değerlerini değiştirmek yerine önce problemin gerçekten nerede olduğunu anlamak lazım.

Network mü?

Capacity drive latency mi?

Cache miss oranı mı?

VM workload’u mu?

Repair işlemi mi çalışıyor?

Storage pool doluluk oranı mı yüksek?

Azure Local’da storage performansı bu katmanların beraber çalışmasının sonucu.

Resiliency backup değildir

Bu konuyu özellikle ayırmak istiyorum.

Three-way mirror kullanıyor olmanız backup yaptığınız anlamına gelmiyor.

Storage Spaces Direct sizi disk ve node gibi fiziksel altyapı arızalarına karşı koruyor.

Ama kullanıcı bir dosyayı sildiyse?

Ransomware VM içerisindeki veriyi şifrelediyse?

Uygulama database’i bozduysa?

Yanlış bir administrator işlemi bütün VM’leri sildiyse?

Aynı hatalı veri Storage Spaces Direct tarafından son derece başarılı şekilde üç kopya halinde tutulabilir.

Yani resiliency ile data protection aynı şey değil.

Bu nedenle Azure Local storage tasarımını yaparken backup ve disaster recovery tasarımını ayrıca yapmak gerekiyor. Serinin ilerleyen bölümünde Azure Local Backup, Disaster Recovery ve Azure Site Recovery tarafını ayrıca ele alacağız.

Storage Spaces Direct’ın görevi altyapı seviyesindeki failure’larda workload’u mümkün olduğunca erişilebilir tutmak ve veriyi korumak.

Backup’ın görevi başka.

İkisini birbirinin alternatifi olarak görmemek gerekiyor.

Azure Local storage mimarisini tasarlarken benim yaklaşımım bu nedenle sadece “kaç TB lazım?” sorusuyla başlamaz.

Workload ne kadar IOPS üretiyor?

Read/write oranı nedir?

Latency beklentisi ne?

Kaç node var?

Aynı anda kaç hardware failure’ını tolere etmek istiyoruz?

All-flash mi hybrid mi?

Three-way mirror’ın kapasite maliyetini kabul edebiliyor muyuz?

Parity kullanmamızı gerektirecek kadar büyük cold veya capacity-oriented data set var mı?

Repair için yeterli reserve capacity bırakıyor muyuz?

Backup ürünü hangi API’leri kullanıyor?

Bunların hepsi storage tasarımının parçası.

Bana göre özellikle Azure Local’da “usable TB başına fiyat” tek başına çok yanıltıcı bir karşılaştırma.

Ucuz görünen storage, failure sonrasında repair yapacak boş alan bırakmıyorsa ucuz değildir.

Daha fazla usable alan sağlıyor diye parity seçip latency-sensitive workload’u yavaşlatıyorsanız verimli değildir.

Üç kopya veriniz var diye backup yapmıyorsanız dayanıklı değildir.

Doğru Azure Local storage tasarımı kapasite, performans ve resiliency arasındaki dengeyi workload’a göre kurmak demek.

Bir sonraki makalede ise Azure Local’ın klasik HCI dünyasının dışına çıktığı en ilginç konulardan birine geçeceğim: Azure Local Disconnected Operations. Azure bağlantısının bulunmadığı ortamlarda local control plane’in nasıl çalıştığını, hangi Azure servislerinin lokal olarak sunulduğunu, management cluster gereksinimini, identity ve update modelini ve “disconnected” ifadesinin neden sadece internet kablosunu çekmek anlamına gelmediğini detaylı olarak inceleyeceğiz.

Kullandığım temel Microsoft kaynakları: Plan volumes on Azure Local and Windows Server clusters, Fault tolerance and storage efficiency, Nested resiliency for Storage Spaces Direct, Understanding the storage pool cache, Replace failed drives on Azure Local, CSV in-memory read cache ve Azure Local Well-Architected Framework.