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, dosya sistemlerini, dayanıklılık türünü ve boyutunu seçme dahil olmak üzere iş yüklerinizin performans ve kapasite gereksinimlerini karşılamak için küme birimlerini planlama hakkında yönergeler sağlanır.

Not

Depolama Alanları Doğrudan genel kullanım için bir dosya sunucusunu 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 nelerdir?

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 ortak olarak 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örünürler.

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

Birimlerin sayısını kümenizdeki sunucu sayısının katı haline getirmenizi öneririz. Örneğin, 4 sunucunuz varsa toplam 4 birimle 3 veya 5'e göre daha tutarlı bir performansla karşılaşırsınız. Bu, kümenin birim "sahipliğini" (bir sunucu her birim için meta veri düzenlemesini işler) sunucular arasında eşit olarak dağıtmasını sağlar.

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 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 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 olan 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 sahip olmanız gerekir. İki yönlü yansıtma, aynı anda 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ıtmalı sunucular arasında veri dayanıklılığı sağlar, ardından iki yönlü yansıtma veya yansıtma 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 eklenen 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 olan 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 sahip olmanız gerekir. Üç 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ılamadığından ve sanal disklere erişilemediğinden 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, 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 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ırılmış 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 sahip olmanız gerekir. Bu, yedi sunucuyla yüzde 66,7 depolama verimliliğine çıkar ve yüzde 80,0'a kadar depolama verimliliğine devam eder. Bunun dezavantajı, eşlik kodlamasının daha yoğun işlem gücüyle 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 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 en yüksek G/Ç gecikmesi ve CPU kullanımı 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. Neredeyse tüm performans örneklerimiz için yansıtmayı kullanırız.

Kapasite en önemli olduğunda

Veri ambarları veya "soğuk" depolama gibi seyrek yazan iş yükleri, depolama verimliliğini en üst düzeye çıkarmak için çift eşlik kullanan birimlerde çalıştırılmalıdır. Genişleme 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şlerde yazan iş yüklerinin başka bir seçeneği vardır: bir birim yansıtmayı ve çift eşliği karıştırabilir. Yazma işlemi önce yansıtılmış bölüme taşını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 alımı hızlandırır ve büyük yazma işlemleri geldiğinde kaynak kullanımını azaltır. Bölümleri boyutlandırırken, bir kerede gerçekleşen yazma miktarının (örneğin, günlük bir 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.

İpucu

Veri alımı yoluyla 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 sonunda aynı türde 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ı, 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 ötesine kadar iyi 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 farklıdır ve depolama havuzunda kaplar toplam fiziksel depolama kapasitesidir. Ayak izi, dayanıklılık türüne bağlıdır. Örneğin, üç yönlü yansıtma kullanan birimlerin boyutunun üç katı bir 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 başarısız olduktan sonra birimlerin "yerinde" onarılması için alan sağlayarak veri güvenliğini ve performansı artırır. Yeterli kapasite varsa, anında ve yerinde bir paralel onarım, başarısız 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ından sonra 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, 4 x 1 = 4 TB'yi yedek olarak ayırın.

Not

Üç türün (NVMe + SSD + HDD) sürücüleri olan kümelerde, her biri 4 sürücüye kadar sunucu başına bir SSD ve 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ırarak arıza yaptıktan sonra sürücüleri değiştirmek için acele etmeden yerinde onarımlar gerçekleştirilebilmesini sağlıyoruz. 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 aynı zamanda çok sayıda soğuk depolama alanımız olduğunu varsayalım: saklamamız gereken eski dosyalar ve yedeklemeler. Dört sunucumuz olduğundan dört birim oluşturalım.

Sanal makineleri ilk iki birime (Birim1 ve Birim2) 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 depolamayı diğer iki birime yerleştirelim: Birim 3 ve Birim 4. Kapasiteyi en üst düzeye çıkarmak için dosya sistemi (Yinelenen Verileri Kaldırma için) ve dayanıklılık için çift eşlik olarak NTFS'yi seçiyoruz.

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

Volume1 ve Volume2'nin her biri 12 TB x yüzde 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 daha sonra istediğiniz zaman genişletebilir veya yeni birimler oluşturabilirsiniz.

Kolaylık olması için, bu örnekte 1 TB = 1.000.000.000.000 bayt anlamına gelen ondalık (taban-10) birimleri kullanılır. Ancak, Windows'taki depolama miktarları ikili (2 tabanındaki) birimlerde 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 bkz:

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