Azure Stack HCI ve Windows Server kümelerinde birimleri planlama

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

Bu makalede, iş yüklerinizin performans ve kapasite gereksinimlerini karşılamak için küme birimlerinin planlanması için dosya sistemlerini, dayanıklılık türlerini ve boyutlarını seçme gibi yönergeler sağlanır.

Not

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

Gözden Geçirme: Birimler nedir?

Birimler, Hyper-V sanal makineleri için VHD veya VHDX dosyaları gibi iş yüklerinizin ihtiyaç duyduğu dosyaları yerleştirdiğiniz yerdir. Birimler, Azure Stack HCI ve Windows Server'ın arkasındaki yazılım tanımlı depolama teknolojisi Depolama Alanları Doğrudan hataya dayanıklılık, ölçeklenebilirlik ve performans avantajlarını tanıtmak için depolama havuzundaki sürücüleri birleştirir.

Not

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 birim ve altındaki sanal diske birlikte başvurmak için "birim" terimini kullanırız. Depolama Alanları Doğrudan başarıyla planlamak ve dağıtmak için bu uygulama düzeyi ayrımlarının anlaşılması gerekmez.

Tüm birimlere kümedeki tüm sunucular aynı anda erişebilir. Oluşturulduktan sonra, tüm sunucularda C:\ClusterStorage\ konumunda gösterilir.

Oluşturulacak birim sayısını seçme

Birim sayısını kümenizdeki sunucu sayısının katı hale getirmenizi öneririz. Örneğin, 4 sunucunuz varsa toplam 4 birimle 3 veya 5'e göre daha tutarlı bir performans elde edebilirsiniz. Bu, kümenin birim "sahipliğini" (bir sunucu her birim için meta veri düzenlemeyi işler) sunucular arasında eşit olarak dağıtmasına olanak tanır.

Toplam birim sayısını küme başına 64 birimle 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 oluşturulmuş premier dosya sistemidir ve önemli performans hızlandırmaları ve veri bozulmasına karşı yerleşik koruma gibi birçok avantaj sunar. Windows Server sürüm 1709 ve sonraki sürümlerde Yinelenen Verileri Kaldırma dahil olmak üzere neredeyse tüm önemli NTFS özelliklerini destekler. Ayrıntılar için bkz. ReFS özellik karşılaştırma tablosu .

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

İpucu

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

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

Depolama Alanları Doğrudan birimleri, 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ılabilirliği etkinleştirmek için dayanıklılık sağlar.

Not

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

İki sunucuyla

Kümedeki iki sunucuyla, iki yönlü yansıtma veya iç içe dayanıklılık kullanabilirsiniz.

İki yönlü yansıtma, her sunucudaki sürücülerde bir kopya olacak şekilde tüm verilerin iki kopyasını 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, bir kerede bir donanım hatasını (bir sunucu veya sürücü) güvenle tolere edebilir.

İç içe dayanıklılık, iki yönlü yansıtmaya sahip sunucular arasında veri dayanıklılığı sağlar, ardından iki yönlü yansıtma veya yansıtması hızlandırılmış eşlik ile 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ırılmış eşlik için yaklaşık yüzde 35-40'tı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üvenle 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. Daha fazla bilgi için bkz. İç içe dayanıklılık.

Üç sunucu ile

Üç sunucuyla, daha iyi hataya dayanıklılık ve performans için üç yönlü yansıtma kullanmanız gerekir. Üç yönlü yansıtma, her sunucudaki sürücülerde bir kopya olacak şekilde 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üvenle tolere edebilir. 2 düğüm kullanılamaz duruma gelirse disklerin 2/3'ünün kullanılabilir olmaması ve sanal disklerin erişilemez olması için depolama havuzu çekirdek kaybeder. Ancak, bir düğüm kapatılabilir ve başka bir düğümdeki bir veya daha fazla disk başarısız olabilir ve sanal diskler çevrimiçi kalır. Örneğin, aniden başka bir sürücü veya sunucu 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 sunucuyla

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

İkili eşlik, üç yönlü yansıtma ile aynı hataya dayanıklılık 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 çıkar ve yüzde 80,0 depolama verimliliğine kadar devam eder. Bunun dezavantajı, eşlik kodlamasının daha yoğun işlem gücü kullanımlı olmasıdır ve bu da performansını sınırlayabilir.

Hangi dayanıklılık türünün kullanılacağı iş yükünüzün gereksinimlerine bağlıdır. Hangi iş yüklerinin her dayanıklılık türüne uygun olduğunu ve her dayanıklılık türünün performansını ve depolama verimliliğini özetleyen bir tablo aşağıdadır.

Dayanıklılık türü	Kapasite verimliliği	Hız	İş yükleri
Ayna	Üç yönlü yansıtma: %33 İki yönlü yansıtma: %50	En yüksek performans	Sanallaştırılmış iş yükleri Veritabanları Diğer yüksek performanslı iş yükleri
Yansıtması hızlandırılmış eşlik	Yansıtma ve eşlik oranına bağlıdır	Yansıtmadan çok daha yavaş, ancak çift eşlikten iki kat daha hızlı Büyük sıralı yazma ve okuma işlemleri için en iyi yöntem	Arşivleme ve yedekleme Sanallaştırılmış masaüstü altyapısı
İkili eşlik	4 sunucu: %50 16 sunucu: %80'e kadar	Yazmalarda CPU kullanımı & en yüksek G/Ç gecikmesi Büyük sıralı yazma ve okuma işlemleri için en iyi yöntem	Arşivleme ve yedekleme Sanallaştırılmış masaüstü altyapısı

Performans en önemli olduğunda

Katı gecikme süresi gereksinimleri olan veya SQL Server veritabanları veya performansa duyarlı Hyper-V sanal makineleri gibi ç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.

İpucu

Yansıtma diğer dayanıklılık türlerinden daha hızlıdır. Yansıtmayı neredeyse tüm performans örneklerimiz için kullanırız.

Kapasite en önemli olduğunda

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ıştırılmalıdır. Scale-Out Dosya Sunucusu (SoFS), sanal masaüstü altyapısı (VDI) gibi diğer bazı iş yükleri veya çok fazla hızlı sürüklenen rastgele GÇ trafiği oluşturmayan ve/veya en iyi performansı gerektirmeyen diğer iş yükleri de sizin 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şlerle yazılan iş yüklerinin başka bir seçeneği vardır: bir birim yansıtma ile çift eşliği karıştırabilir. Yazma işlemi ilk olarak yansıtılmış kısımda yer alır ve daha sonra kademeli olarak eşlik bölümüne taşınır. Bu işlem yoğunluklu eşlik kodlamasının daha uzun bir süre boyunca gerçekleşmesini sağlayarak büyük yazma işlemleri geldiğinde alımı hızlandırır ve kaynak kullanımını azaltır. Bölümleri boyutlandırırken, aynı anda gerçekleşen yazma miktarının (örneğin, bir günlük yedekleme) yansıtma bölümüne rahatça sığması gerektiğini göz önünde bulundurun. Örneğin, günde bir kez 100 GB alırsanız, 150 GB ile 200 GB arasında yansıtma ve geri kalanı için çift eşlik kullanmayı göz önünde bulundurun.

Sonuçta elde edilen depolama verimliliği, seçtiğiniz oranlara bağlıdır. Bazı örnekler için bu tanıtıma bakın.

İpucu

Veri alımı aracılığıyla 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ırılmış eşlikin kullanım örneğiniz için uygun olmadığını gösterebilir. Örneğin, yazma performansı 400 MB/sn'den 40 MB/sn'ye düşüyorsa yansıtma bölümünü genişletmeyi veya üç yönlü yansıtmaya geçmeyi göz önünde bulundurun.

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

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

Üç sürücü türünün de bulunduğu 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) bırakır. Her birim için tamamen SSD katmanında mı yoksa tamamen HDD katmanında mı yoksa ikisine mi yayıldığını seçebilirsiniz.

Önemli

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.

İpucu

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

Ayak izi

Birimin boyutu kullanılabilir kapasitesine, depolanabileceği veri miktarına karşılık gelir. Bu, New-Volume cmdlet'inin -Size parametresi tarafından sağlanır ve Get-Volume cmdlet'ini çalıştırdığınızda Boyut özelliğinde görüntülenir.

Boyut birimin ayak izinden, depolama havuzunda kapsamış olduğu toplam fiziksel depolama kapasitesinden farklıdır. Ayak izi dayanıklılık türüne bağlıdır. Örneğin, üç yönlü yansıtma kullanan birimlerin boyutunun üç katı ayak izi vardır.

Birimlerinizin ayak izlerinin depolama havuzuna sığacak şekilde olması gerekir.

Yedek kapasite

Depolama havuzunda bir miktar kapasitenin ayrılmamış olarak bırakılması, sürücüler arızalandıktan sonra "yerinde" onarım için birimlere alan sağlayarak veri güvenliğini ve performansı artırır. Yeterli kapasite varsa, hemen yerinde, paralel 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 kapasite sürücüsünün eşdeğerini ayırmanızı öneririz. Kendi takdirinize bağlı olarak daha fazla rezervasyon yapabilirsiniz, ancak bu minimum öneri, herhangi bir sürücü arızası sonrasında anında, yerinde paralel onarımın başarılı olabileceğini garanti eder.

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

Not

Her üç türden sürücüye (NVMe + SSD + HDD) sahip kümelerde, her biri 4 sürücüye kadar bir SSD ile sunucu başına bir HDD eşdeğerini 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ı 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'den dört sürücü veya 8 TB ayırıyoruz, böylece arıza yaptıktan sonra sürücüleri değiştirmek için acele etmeden yerinde onarımlar gerçekleşebilir. Bu, birim oluşturabildiğimiz havuzda 120 TB fiziksel depolama kapasitesi bırakır.

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

Bazı yüksek oranda etkin Hyper-V sanal makinelerini barındırmak için dağıtımımıza ihtiyacımız olduğunu, ancak saklamamız gereken çok sayıda soğuk depolama alanımız olduğunu varsayalım: eski dosyalar ve yedeklemeler. Dört sunucumuz olduğundan dört birim oluşturalım.

Sanal makineleri ilk iki birime ( Volume1 ve Volume2) yerleştirelim. Performansı en üst düzeye çıkarmak için dosya sistemi (daha hızlı oluşturma ve denetim noktaları için) ve dayanıklılık için üç yönlü yansıtma olarak ReFS'yi seçiyoruz. Soğuk depolama alanını diğer iki birime ( Birim 3 ve Birim 4) yerleştirelim. 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şlik'i seçiyoruz.

Tüm birimleri aynı boyutta yapmamız gerekmez, ancak kolaylık olması için hepsini 12 TB yapabiliriz.

Volume1 ve Volume2'nin her biri 12 TB x 33,3 verimlilik = 36 TB fiziksel depolama kapasitesi kaplar.

Volume3 ve Volume4'ün her biri 12 TB x yüzde 50,0 verimlilik = 24 TB fiziksel depolama kapasitesi kaplar.

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

Dört birim, havuzumuzda bulunan fiziksel depolama kapasitesine tam olarak uygundur. Mükemmel!

İpucu

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

Kolaylık olması için, bu örnek genelinde ondalık (10 tabanı) birimleri kullanır; yani 1 TB = 1.000.000.000.000 bayt. Ancak, Windows'taki depolama miktarları ikili (2 tabanında) birimler halinde görünür. Örneğin, her 2 TB 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.

Kullanım

Bkz. Azure Stack HCI'de birim oluşturma.

Sonraki adımlar

Daha fazla bilgi için ayrıca bkz:

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