Sunucu kümelerini Azure Stack HCI Windows birimleri planlama

Uygulama: Azure Stack HCI, sürüm 21H2 ve 20H2; Windows Server 2022, Windows Server 2019

Bu makalede, iş yüklerinin performans ve kapasite ihtiyaçlarını karşılamak için küme birimlerini planlamaya yönelik rehberlik ve bunların dosya sistemi, güvenlik türü ve boyutunu seçme de dahil olmak üzere sağlanmıştır.

Gözden geçirme: Birimler nedir?

Birimler, Hyper-V sanal makineleri için VHD veya VHDX dosyaları gibi iş yüklerinizi gereken dosyaları nereye koyabilirsiniz? Birimler, yazılım tanımlı depolama teknolojisi olan Depolama Alanları Direct'inhataya dayanıklılık, ölçeklenebilirlik ve performans avantajlarını tanıtmak için depolama havuzu üzerindeki sürücüleri Azure Stack HCI.

Tüm birimlere kümenin tüm sunucuları tarafından aynı anda erişilebilir. Oluşturulduktan sonra tüm sunucularda C:\ClusterStorage\ konumundalar.

Oluşturul birden fazla birim seçme

Birim sayısını kümenizin sunucu sayısının katlarına oluşturmanızı öneririz. Örneğin, 4 sunucu varsa, toplam 4 birim ile 3 veya 5'e göre daha tutarlı bir performans elde edin. Bu, kümenin "sahiplik" birimini (bir sunucu her birim için meta veri düzenlemeyi işlemesi) sunucular arasında eşit olarak dağıtmaya olanak sağlar.

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

Dosya sistemi seçme

Depolama Alanları Direct için yeni Resilient File System (ReFS) Depolama Alanları öneririz. ReFS, sanallaştırma için özel olarak inşa edilen 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 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 desteklememiş olduğu bir özellik gerektiriyorsa, bunun yerine NTFS'yi kullanabilirsiniz.

Resiliency türünü seçme

Depolama Alanları Direct'te birimler, sürücü veya sunucu hataları gibi donanım sorunlarına karşı koruma ve yazılım güncelleştirmeleri gibi sunucu bakımı boyunca sürekli kullanılabilirliği etkinleştirmeye yönelik bir güvenlik sağlar.

İki sunucu ile

Kümede iki sunucuyla iki yol yansıtma kullanabilir veya iç içe geçmiş bir resilians kullanabilirsiniz.

İki yol yansıtma, tüm verilerin iki kopyasını tutar ve her sunucudaki sürücülerde bir kopya olur. 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 yollı yansıtma, aynı anda bir donanım hatasına (bir sunucu veya sürücü) güvenli bir şekilde tolerans gösterir.

İç içe geçmiş resilians, iki yol yansıtmalı sunucular arasında veri resiliansı sağlar, ardından iki yol yansıtmalı veya yansıtma hızlandırılmış eşlikli bir sunucu içinde bir sunucuya karşı koruma sağlar. İç içe yerleştirme, bir sunucu yeniden başlatıldığında veya kullanılamasa bile veriye karşı koruma sağlar. Depolama verimliliği, iç içe çift yollu yansıtma ile yüzde 25 ve iç içe yansıtma hızlandırmalı eşlik için yaklaşık yüzde 35-40'tır. İç içe geçmiş güvenlik, aynı anda iki donanım arızasını (iki sürücü veya bir sunucu ve kalan sunucu üzerinde bir sürücü) güvenli bir şekilde tolere ediyor olabilir. Eklenen bu veriye karşı daha fazla koruma nedeniyle, iki sunuculı kümelerin üretim dağıtımları üzerinde iç içe geçmiş bir resilians kullanılması önerilir. Daha fazla bilgi için bkz. İç içe geçmiş resiliency.

Üç sunucu ile

Üç sunucuyla, daha iyi hataya dayanıklılık ve performans için üç yol yansıtma kullanabilirsiniz. Üç yol yansıtma tüm verilerin üç kopyasını tutar ve her sunucudaki sürücülerde bir kopya olur. Depolama verimliliği yüzde 33,3'tü. 1 TB veri yazmak için depolama havuzunda en az 3 TB fiziksel depolama kapasitesine ihtiyacınız vardır. Üç yol yansıtma aynı anda en az iki donanım sorununa (sürücü veya sunucu) güvenle tolere olabilir. 2 düğüm kullanılamaz duruma gelirse, disklerin 2/3'ü kullanılabilir olmadığı ve sanal disklerin erişilemez olduğu için depolama havuzu çekirdek kaybeder. Ancak, bir düğüm arızalı olabilir 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 sunucu ile

Dört veya daha fazla sunucuyla her birim için üç yol yansıtma, çift eşlik (genellikle "silme kodlaması" olarak da adlandırılan) kullanmayı veya bu iki birimi yansıtma hızlandırılmış eşlik ile karıştırmayı seçebilirsiniz.

Çift eşlik, üç yollu yansıtma ile aynı hataya dayanıklılık sağlar ancak daha iyi depolama verimliliği sağlar. Dört sunucuyla 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'ye kadar depolama verimliliğine ve yüzde 80,0'a kadar depolama verimliliğine devam eder. Burada önemli olan, eşlik kodlamasını daha yoğun işlem gücüyle sınırlamaktır ve bu da performansını sınırlar.

Hangi resilians türünü kullanmak, iş yük gerektirmektedir. Aşağıda, hangi iş yüklerinin her bir resilicy türüne uygun olduğu ve her bir resiliency türünün performans ve depolama verimliliği için uygun olduğu özetlenmiştir.

Dayanıklılık türü	Kapasite verimliliği	Hız	İş yükleri
Ayna	Üç yol yansıtma: %33 İki yollı yansıtma: %50	En yüksek performans	Sanallaştırılmış iş yükleri Veritabanları Diğer yüksek performanslı iş yükleri
Yansıtmalı 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ı yazmalar ve okumalar için en iyi	Arşivleme ve yedekleme Sanallaştırılmış masaüstü altyapısı
Çift eşlik	4 sunucu: %50 16 sunucu: %80'e kadar	Yazmalarda en yüksek I/O & gecikme süresi CPU kullanımı Büyük sıralı yazmalar ve okumalar için en iyi	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'ye ihtiyacı olan iş yükleri, performansı en üst düzeye çıkarmak için yansıtma kullanan birimlerde çalışmalıdır.

Kapasite en önemli olduğunda

Veri ambarları veya "soğuk" depolama gibi seyrek olarak yazma işlemi yapılan iş yüklerinin, depolama verimliliğini en üst düzeye çıkarmak için çift eşlik kullanan birimlerde çalışması gerekir. Geleneksel dosya sunucuları, sanal masaüstü altyapısı (VDI) gibi bazı diğer iş yükleri veya çok fazla hızlı kaymaya neden olan rastgele GÇ trafiği oluşturmayen ve/veya en iyi performansı gerektirmeyen diğer bazı iş yükleri de kendi takdirine bağlı olarak çift eşlik kullanabilir. Eşlik, özellikle yazmalarda yansıtmaya kıyasla CPU kullanımını ve IO gecikme süresini kaçınılmaz olarak artırır.

Veriler toplu olarak yazıldığı zaman

Arşivleme veya yedekleme hedefleri gibi büyük, sıralı geçişler ile yazma iş yüklerinin başka bir seçeneği vardır: bir birim yansıtmayı ve çift eşlikyi karıştırabilir. Yazmalar önce yansıtılmış bölüme iner ve daha sonra kademeli olarak eşlik bölümüne taşınır. Bu işlem yoğun eşlik kodlamasını daha uzun bir süre içinde sağlayarak alımı hızlandırır ve büyük yazmalar geldiğinde kaynak kullanımını azaltır. Bölümleri boyutlandırırken, aynı anda (örneğin, bir günlük yedekleme) gerçekleşecek yazma miktarının yansıtma bölümüne uygun olması gerektiğini göz önünde bulundurarak. Örneğin, günde bir kez 100 GB alan varsa 150 GB ile 200 GB arasında yansıtma ve geri kalanı için çift eşlik kullanmayı göz önünde bulundurarak.

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.

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 yavaş sürücüler kapasite sağlar. Bu otomatik olarak gerçekleşir – daha fazla bilgi için bkz. Direct'te Depolama Alanları anlama. Bu tür dağıtımlarda, tüm birimler sonuç olarak aynı sürücü türünde (kapasite sürücüleri) yer alar.

Üç sürücü türü de olan dağıtımlarda, yalnızca en hızlı sürücüler (NVMe) önbelleğe alma sağlar ve iki tür sürücü (SSD ve HDD) kapasite sağlar. Her birim için, tamamen SSD katmanında mı, tamamen HDD katmanında mı yoksa bu katmana mı yaylımlı olduğunu seçebilirsiniz.

Birimlerin boyutunu seçme

Server 2019'da her birimin boyutunu 64 TB Windows öneririz.

Ayak izi

Bir birimin boyutu, kullanılabilir kapasitesine ve depolanabilir veri miktarına başvurur. Bu, New-Volume cmdlet'inin -Size parametresi tarafından sağlanır ve ardından Get-Volume cmdlet'ini çalıştırarak Size özelliğinde görünür.

Boyut, birimin ayak izinden ,depolama havuzunda kapladığı toplam fiziksel depolama kapasitesinden farklıdır. Ayak izi, kendi resilians türüne bağlıdır. Örneğin, üç yol yansıtma kullanan birimler boyutunun üç katı ayak izine sahip olur.

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

Kapasiteyi yedekle

Bazı kapasiteleri depolama havuzunda ayrılmamış olarak bırakmak, sürücüler başarısız olduktan sonra birimlerin "yerinde" onarılması için alan sağlar ve veri güvenliğini ve performansını artırır. Yeterli kapasite varsa, arızalı sürücüler değiştirilene kadar hemen, yerinde, paralel onarım birimleri tam resiliye geri yükleyebilir. Bu otomatik olarak gerçekleşir.

Sunucu başına en fazla 4 sürücü olmak için bir kapasite sürücüsüne eşdeğer bir değerden tasarruf etmek önerilir. Kendi takdirine bağlı olarak daha fazlasını yedeklersiniz, ancak bu en düşük öneri herhangi bir sürücü arızası sonrasında hemen, yerinde, paralel onarımın başarılı olalarını garanti eder.

Örneğin, 2 sunucusu varsa ve 1 TB kapasite sürücüsü kullanıyorsanız, havuzun 2 x 1 = 2 TB'lık bir yerine yedek olarak ayarlayın. 3 sunucusu ve 1 TB kapasite sürücü varsa, yedek olarak 3 x 1 = 3 TB'ı ayırabilirsiniz. 4 veya daha fazla sunucusu ve 1 TB kapasite sürücü varsa, yedek olarak 4 x 1 = 4 TB'ı ayırabilirsiniz.

Örnek: Kapasite planlaması

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

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

Depolama havuzunda bulunan bu 128 TB'den dört veya 8 TB'lık bir disk ayırarak arıza sonrasında yerinde onarımlar yapmak için sürücülerin değiştirilmesinde herhangi bir yük olmayacaktır. Bu, birimleri oluşturamak için havuza 120 TB fiziksel depolama kapasitesi bırakır.

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

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 (eski dosyalar ve yedeklemeler) saklamamız gerekir. Dört sunucu olduğundan dört birim oluşturabilirsiniz.

Şimdi sanal makineleri ilk iki birimlere koyarak Birim1 ve Birim2'ye bakalım. Dosya sistemi olarak ReFS'yi (daha hızlı oluşturma ve denetim noktaları için) ve performansı en üst düzeye çıkarmak için üç yol yansıtmayı seçerek performansı en üst düzeye çıkaracağız. Şimdi durarak depolama alanını diğer iki birimde (Birim 3 ve Birim 4) koyabilirsiniz. Kapasiteyi en üst düzeye çıkarmak için dosya sistemi olarak NTFS 'yi (Veri Kaldırma için) ve çift eşlik olarak da sağlayabilirsiniz.

Tüm birimleri aynı boyutta yapmamız gerekmez, ancak kolaylık olması için 12 TB'lık bir boyuta sahip olabiliriz.

Birim1 ve Birim2'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 uyar. Mükemmel!

Kolaylık olması için bu örnekte ondalık (temel-10) birimler 1 TB = 1.000.000.000.000 bayt anlamına gelir. Ancak, depolama miktarı Windows ikili (base-2) birimlerde görünür. Örneğin, her 2 TB sürücü, sürücülerde 1,82 TiB Windows. Benzer şekilde, 128 TB depolama havuzu 116,41 TiB olarak görünür. Bu beklenen bir durumdur.

Kullanım

Bkz. Azure Stack HCI.

Sonraki adımlar

Daha fazla bilgi için bkz.

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