Azure Stack HCI ve Windows Server kümelerinde birim planlama

Şunlar için geçerlidir: Azure Stack HCI, sürüm 22H2 ve 21H2; Windows Server 2022, Windows Server 2019

Bu makalede, dosya sistemlerini, dayanıklılık türünü ve boyutunu seçme de dahil olmak üzere iş yüklerinizin performans ve kapasite gereksinimlerini karşılamak için küme birimlerini planlamaya yönelik yönergeler sağlanır.

Note

Depolama Alanları Doğrudan, genel kullanım için bir dosya sunucusunu desteklemez. Dosya sunucusunu veya diğer genel hizmetleri Depolama Alanı Doğrudan'da çalıştırmanız gerekiyorsa, bunu sanal makinelerde yapılandırın.

İnceleme: Hacimler nedir

Birimler, VHD veya Hyper-V sanal makineler için VHDX dosyaları gibi iş yüklerinizin ihtiyaç duyduğu dosyaları koyduğunuz yerdir. Birimler, Azure Stack HCI ve Windows Server'ın arkasındaki yazılım tanımlı depolama teknolojisi olan Storage Spaces Direct'in hata toleransı, ölçeklenebilirlik ve performans avantajlarını sunmak için depolama havuzundaki sürücüleri birleştirir.

Note

"Birim" terimini, Küme Paylaşılan Birimleri (CSV) ve ReFS gibi diğer yerleşik Windows özellikleri tarafından sağlanan işlevler de dahil olmak üzere, birime ve altındaki sanal diske ortak olarak atıfta bulunmak için kullanırız. Depolama Alanları Doğrudan'ı başarılı bir şekilde planlamak ve dağıtmak için bu uygulama düzeyi ayrımlarını anlamak gerekli değildir.

Tüm birimlere kümedeki tüm sunucular tarafından aynı anda erişilebilir. Once created, they show up at C:\ClusterStorage\ on all servers.

Kaç birim oluşturulacağını seçme

Birim sayısını kümenizdeki sunucu sayısının katları yapmanızı öneririz. Örneğin, 4 sunucunuz varsa, toplam 4 birimle 3 veya 5 birime göre daha tutarlı performans elde edersiniz. Bu, kümenin birim "sahipliğini" (her birim için meta veri düzenlemesini bir sunucu gerçekleştirir) sunucular arasında eşit olarak dağıtmasına olanak tanır.

Toplam birim sayısını küme başına 64 birim ile sınırlamanızı öneririz.

Dosya sistemini seçme

Depolama Alanları Doğrudan için yeni Dayanıklı Dosya Sistemi'ni (ReFS) kullanmanızı öneririz. ReFS, sanallaştırma için özel olarak oluşturulmuş önde gelen dosya sistemidir ve dramatik performans hızlandırmaları ve veri bozulmasına karşı yerleşik koruma dahil olmak üzere birçok avantaj sunar. Windows Server sürüm 1709 ve sonraki sürümlerde Yinelenen Verileri Kaldırma da dahil olmak üzere neredeyse tüm önemli NTFS özelliklerini destekler. Ayrıntılar için ReFS özellik karşılaştırma tablosuna bakın.

İş yükünüz ReFS'nin henüz desteklemediği bir özellik gerektiriyorsa, bunun yerine NTFS'yi kullanabilirsiniz.

Tip

Farklı dosya sistemlerine sahip birimler aynı kümede bir arada bulunabilir.

Dayanıklılık türünü seçme

Depolama Alanları Doğrudan'daki birimler, sürücü veya sunucu hataları gibi donanım sorunlarına karşı koruma sağlamak ve yazılım güncelleştirmeleri gibi sunucu bakımı boyunca sürekli kullanılabilirlik sağlamak için dayanıklılık sağlar.

Note

Hangi dayanıklılık türlerini seçebileceğiniz, sahip olduğunuz sürücü türlerinden bağımsızdır.

İki sunucu ile

Kümede iki sunucu varken iki yönlü yansıtma kullanabilir veya iç içe dayanıklılık kullanabilirsiniz.

İki yönlü yansıtma, tüm verilerin iki kopyasını, her sunucudaki sürücülerde bir kopya tutar. Depolama verimliliği yüzde 50'dir; 1 TB veri yazmak için depolama havuzunda en az 2 TB fiziksel depolama kapasitesine ihtiyacınız vardır. İki yönlü yansıtma, aynı anda bir donanım arızasını (bir sunucu veya sürücü) güvenli bir şekilde tolere edebilir.

İç içe dayanıklılık, iki yönlü yansıtma ile sunucular arasında veri dayanıklılığı sağlar, ardından iki yönlü yansıtma veya yansıtma hızlandırmalı eşlik ile bir sunucu içinde dayanıklılık ekler. İç içe yerleştirme, bir sunucu yeniden başlatıldığında veya kullanılamadığında bile veri dayanıklılığı sağlar. Depolama verimliliği, iç içe iki yönlü yansıtma ile yüzde 25 ve iç içe yansıtma hızlandırmalı eşlik için yüzde 35-40 civarındadır. İç içe dayanıklılık, aynı anda iki donanım hatasını (iki sürücü veya bir sunucu ve kalan sunucudaki bir sürücü) güvenli bir şekilde tolere edebilir. Bu ek veri dayanıklılığı nedeniyle, iki sunuculu kümelerin üretim dağıtımlarında iç içe dayanıklılık kullanmanızı öneririz. For more info, see Nested resiliency.

Üç sunucu ile

Üç sunucuyla, daha iyi hata toleransı ve performans için üç yönlü yansıtma kullanmanız gerekir. Üç yönlü yansıtma, her sunucudaki sürücülerde bir kopya olmak üzere tüm verilerin üç kopyasını tutar. Depolama verimliliği yüzde 33,3'tür – 1 TB veri yazmak için depolama havuzunda en az 3 TB fiziksel depolama kapasitesine ihtiyacınız vardır. Üç yönlü yansıtma, aynı anda en az iki donanım sorununu (sürücü veya sunucu) güvenli bir şekilde tolere edebilir. 2 düğüm kullanılamaz duruma gelirse, disklerin 2/3'ü kullanılamadığından ve sanal disklere erişilemediğinden depolama havuzu çekirdeği kaybeder. Ancak, bir düğüm kapalı olabilir ve başka bir düğümdeki bir veya daha fazla disk başarısız olabilir ve sanal diskler çevrimiçi kalabilir. Örneğin, başka bir sürücü veya sunucu aniden başarısız olduğunda bir sunucuyu yeniden başlatıyorsanız, tüm veriler güvenli ve sürekli erişilebilir durumda kalır.

Dört veya daha fazla sunucu ile

Dört veya daha fazla sunucuyla, her birim için üç yönlü yansıtma, çift eşlik (genellikle "silme kodlaması" olarak adlandırılır) kullanmayı veya ikisini yansıtma hızlandırmalı eşlik ile karıştırmayı seçebilirsiniz.

Çift eşlik, üç yönlü yansıtma ile aynı hata toleransını sağlar, ancak daha iyi depolama verimliliği sağlar. Dört sunucu ile depolama verimliliği yüzde 50.0'dır; 2 TB veri depolamak için depolama havuzunda 4 TB fiziksel depolama kapasitesine ihtiyacınız vardır. Bu, yedi sunucuyla yüzde 66,7 depolama verimliliğine yükselir ve yüzde 80,0 depolama verimliliğine kadar devam eder. Bunun karşılığı, eşlik kodlamasının daha yoğun işlem yoğun olması ve bu da performansını sınırlayabilmesidir.

Hangi dayanıklılık türünün kullanılacağı, ortamınızın performans ve kapasite gereksinimlerine bağlıdır. Aşağıda, her dayanıklılık türünün performansını ve depolama verimliliğini özetleyen bir tablo verilmiştir.

Resiliency type	Capacity efficiency	Speed
Mirror	Üç yönlü ayna: 33% Two-way-mirror: 50%	Highest performance
Mirror-accelerated parity	Ayna ve parite oranına bağlıdır	Aynadan çok daha yavaş, ancak çift eşlikten iki kata kadar daha hızlı Büyük sıralı yazma ve okuma işlemleri için en iyisi
Dual-parity	4 sunucu: 50% 16 sunucu: 80%'ye kadar	Yazma işlemlerinde en yüksek G/Ç gecikme süresi ve CPU kullanımı Büyük sıralı yazma ve okuma işlemleri için en iyisi

Performansın en önemli olduğu anlar

SQL Server veritabanları veya performansa duyarlı Hyper-V sanal makineler gibi katı gecikme süresi gereksinimleri olan veya çok sayıda karma rastgele IOPS gerektiren iş yükleri, performansı en üst düzeye çıkarmak için yansıtma kullanan birimlerde çalıştırılmalıdır.

Tip

Yansıtma, diğer dayanıklılık türlerinden daha hızlıdır. Neredeyse tüm performans örneklerimiz için yansıtma kullanıyoruz.

Kapasitenin en önemli olduğu anlar

Veri ambarları veya "soğuk" depolama gibi seyrek yazılan iş yükleri, depolama verimliliğini en üst düzeye çıkarmak için çift eşlik kullanan birimlerde çalışmalıdır. Scale-Out Dosya Sunucusu (SoFS), sanal masaüstü altyapısı (VDI) veya çok sayıda hızlı sürüklenen rastgele GÇ trafiği oluşturmayan ve/veya en iyi performansı gerektirmeyen diğer bazı iş yükleri de kendi takdirinize bağlı olarak çift eşlik kullanabilir. Eşlik, yansıtmaya kıyasla özellikle yazma işlemlerinde CPU kullanımını ve GÇ gecikme süresini kaçınılmaz olarak artırır.

Veriler toplu olarak yazıldığında

Arşivleme veya yedekleme hedefleri gibi büyük, sıralı geçişlerde yazan iş yüklerinin başka bir seçeneği daha vardır: tek bir birim yansıtma ve çift eşliği karıştırabilir. Yazma işlemleri önce yansıtılmış bölümde başlar ve daha sonra kademeli olarak eşlik bölümüne taşınır. Bu, işlem açısından yoğun eşlik kodlamasının daha uzun bir süre boyunca gerçekleşmesine olanak tanıyarak büyük yazmalar geldiğinde alımı hızlandırır ve kaynak kullanımını azaltır. Bölümleri boyutlandırırken, bir kerede gerçekleşen yazma miktarının (bir günlük yedekleme gibi) ayna bölümüne rahatça sığması gerektiğini göz önünde bulundurun. Örneğin, günde bir kez 100 GB alıyorsanız, 150 GB ile 200 GB arasında yansıtma ve geri kalanı için çift eşlik kullanmayı göz önünde bulundurun.

Ortaya çıkan depolama verimliliği, seçtiğiniz oranlara bağlıdır.

Tip

Veri alımının bir bölümünde yazma performansında ani bir düşüş gözlemlerseniz, yansıtma bölümünün yeterince büyük olmadığını veya yansıtma hızlandırmalı eşliğin kullanım örneğiniz için uygun olmadığını gösterebilir. Örnek olarak, yazma performansı 400 MB/sn'den 40 MB/sn'ye düşerse, yansıtma bölümünü genişletmeyi veya üç yönlü yansıtmaya geçmeyi düşünün.

NVMe, SSD ve HDD ile dağıtımlar hakkında

İki tür sürücüye sahip dağıtımlarda, daha hızlı sürücüler önbelleğe alma sağlarken, daha yavaş sürücüler kapasite sağlar. Bu otomatik olarak gerçekleşir – daha fazla bilgi için Depolama Alanları Doğrudan'da önbelleği anlama bölümüne bakın. Bu tür dağıtımlarda, tüm birimler sonuçta aynı tür sürücülerde (kapasite sürücüleri) bulunur.

Her üç sürücü türüne de sahip dağıtımlarda, yalnızca en hızlı sürücüler (NVMe) önbelleğe alma sağlar ve kapasite sağlamak için iki tür sürücü (SSD ve HDD) kalır. Her birim için, tamamen SSD katmanında mı, tamamen HDD katmanında mı yoksa ikisine mi yayılacağını seçebilirsiniz.

Important

Performansa en duyarlı iş yüklerinizi tümü flash'a yerleştirmek için SSD katmanını kullanmanızı öneririz.

Birimlerin boyutunu seçme

Azure Stack HCI'de her birimin boyutunu 64 TB ile sınırlamanızı öneririz.

Tip

Dosya sunucusu iş yüklerinde olduğu gibi, Birim Gölge Kopyası hizmetine (VSS) ve Volsnap yazılım sağlayıcısına dayanan bir yedekleme çözümü kullanıyorsanız, birim boyutunu 10 TB ile sınırlamak performansı ve güvenilirliği artıracaktır. Daha yeni Hyper-V RCT API'sini ve/veya ReFS blok klonlamayı ve/veya yerel SQL yedekleme API'lerini kullanan yedekleme çözümleri, 32 TB ve ötesine kadar iyi performans gösterir.

Footprint

Bir birimin boyutu, kullanılabilir kapasitesini, depolayabileceği veri miktarını ifade eder. This is provided by the -Size parameter of the New-Volume cmdlet and then appears in the Size property when you run the Get-Volume cmdlet.

Size is distinct from volume's footprint, the total physical storage capacity it occupies on the storage pool. Ayak izi, dayanıklılık türüne bağlıdır. Örneğin, üç yönlü yansıtma kullanan birimler, boyutlarının üç katı bir ayak izine sahiptir.

Birimlerinizin ayak izlerinin depolama havuzuna sığması gerekir.

Reserve capacity

Depolama havuzunda bir miktar kapasitenin ayrılmadan bırakılması, sürücüler arızalandıktan sonra birimlere "yerinde" onarım için alan sağlayarak veri güvenliğini ve performansını artırır. Yeterli kapasite varsa, anında, yerinde, paralel bir onarım, arızalı sürücüler değiştirilmeden önce bile birimleri tam dayanıklılığa geri yükleyebilir. Bu otomatik olarak gerçekleşir.

Sunucu başına en fazla 4 sürücü olmak üzere bir kapasiteye eşdeğer sürücü ayırmanızı öneririz. Kendi takdirinize bağlı olarak daha fazlasını rezerve edebilirsiniz, ancak bu minimum öneri, herhangi bir sürücünün arızalanmasından sonra anında, yerinde, paralel bir onarımın başarılı olabileceğini garanti eder.

Örneğin, 2 sunucunuz varsa ve 1 TB kapasiteli sürücüler kullanıyorsanız, havuzun 2 x 1 = 2 TB'ını yedek olarak ayırın. 3 sunucunuz ve 1 TB kapasiteli sürücünüz varsa, 3 x 1 = 3 TB'ı yedek olarak ayırın. 4 veya daha fazla sunucunuz ve 1 TB kapasiteli sürücünüz varsa, 4 x 1 = 4 TB'ı yedek olarak ayırın.

Note

Her üç türden de (NVMe + SSD + HDD) oluşan kümelerde, sunucu başına bir SSD artı bir HDD eşdeğerini, her birinden en fazla 4 sürücü ayırmanızı öneririz.

Örnek: Kapasite planlaması

Dört sunuculu bir küme düşünün. Her sunucunun bazı önbellek sürücüleri ve kapasite için on altı adet 2 TB sürücüsü vardır.

4 servers x 16 drives each x 2 TB each = 128 TB

Depolama havuzundaki bu 128 TB'tan dört sürücü veya 8 TB ayırdık, böylece yerinde onarımlar, arızalandıktan sonra sürücüleri değiştirmek için acele etmeden gerçekleşebilir. Bu, havuzda birimler oluşturabileceğimiz 120 TB fiziksel depolama kapasitesi bırakır.

128 TB – (4 x 2 TB) = 120 TB

Bazı son derece aktif Hyper-V sanal makinelerini barındırmak için dağıtımımıza ihtiyacımız olduğunu varsayalım, ancak aynı zamanda çok sayıda soğuk depolamamız var - saklamamız gereken eski dosyalar ve yedeklemeler. Dört sunucumuz olduğu için dört birim oluşturalım.

Let's put the virtual machines on the first two volumes, Volume1 and Volume2. Dosya sistemi olarak ReFS'yi (daha hızlı oluşturma ve kontrol noktaları için) ve performansı en üst düzeye çıkarmak için esneklik için üç yönlü yansıtmayı seçiyoruz. Let's put the cold storage on the other two volumes, Volume 3 and Volume 4. Dosya sistemi olarak NTFS'yi (Yinelenen Verileri Kaldırma için) ve kapasiteyi en üst düzeye çıkarmak için dayanıklılık için çift eşliği seçiyoruz.

Tüm birimleri aynı boyutta yapmamız gerekmiyor, ancak basitlik için örneğin hepsini 12 TB yapabiliriz.

Volume1 and Volume2 each occupy 12 TB x 33.3 percent efficiency = 36 TB of physical storage capacity.

Volume3 and Volume4 each occupy 12 TB x 50.0 percent efficiency = 24 TB of physical storage capacity.

36 TB + 36 TB + 24 TB + 24 TB = 120 TB

Dört birim, havuzumuzda bulunan fiziksel depolama kapasitesine tam olarak uyar. Perfect!

Tip

Tüm birimleri hemen oluşturmanız gerekmez. Birimleri her zaman genişletebilir veya daha sonra yeni birimler oluşturabilirsiniz.

Kolaylık olması için, bu örnekte ondalık (10 tabanlı) birimler kullanılır, yani 1 TB = 1.000.000.000.000 bayt. Ancak, Windows'taki depolama miktarları ikili (2 taban) birimler halinde görünür. Örneğin, her 2 TB'lık sürücü Windows'ta 1,82 TiB olarak görünür. Benzer şekilde, 128 TB depolama havuzu 116,41 TiB olarak görünür. Bu beklenen bir durumdur.

Usage

See Creating volumes.

Next steps

Daha fazla bilgi için bkz:

• Depolama Alanları Doğrudan için sürücü seçme
• hataya dayanıklılık ve depolama verimliliği