Depolama Alanları Doğrudan için iç içe dayanıklılık

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

İç içe dayanıklılık, Azure Stack HCI ve Windows Server'da Depolama Alanları Doğrudan özelliğidir. İki sunuculu bir kümenin depolama kullanılabilirliği kaybı olmadan aynı anda birden çok donanım hatasına dayanmasını sağlar, böylece kullanıcılar, uygulamalar ve sanal makineler kesintiye uğramadan çalışmaya devam eder. Bu makalede iç içe dayanıklılığın nasıl çalıştığı açıklanır, kullanmaya başlamak için adım adım yönergeler sağlanır ve en sık sorulan soruları yanıtlar.

Başlamadan önce

Aşağıdakiler durumunda iç içe dayanıklılığı göz önünde bulundurun:

  • Kümeniz şu işletim sistemlerinden birini çalıştırır: Azure Stack HCI, sürüm 21H2, Azure Stack HCI, sürüm 20H2, Windows Server 2022 veya Windows Server 2019; Ve
  • Kümenizin tam olarak iki sunucu düğümü vardır.

İç içe dayanıklılık şu durumlara karşı kullanılamaz:

  • Kümeniz Windows Server 2016 çalışır; veya
  • Kümenizin yalnızca tek bir sunucu düğümü veya üç veya daha fazla sunucu düğümü var.

Neden iç içe dayanıklılık

İç içe dayanıklılık kullanan birimler, klasik iki yönlü yansıtma dayanıklılığından farklı olarak, aynı anda birden çok donanım hatası olsa bile çevrimiçi ve erişilebilir durumda kalabilir. Örneğin, iki sürücü aynı anda başarısız olursa veya bir sunucu kapanırsa ve bir sürücü başarısız olursa, iç içe dayanıklılık kullanan birimler çevrimiçi ve erişilebilir kalır. Hiper yakınsama altyapısı için bu, uygulamalar ve sanal makineler için çalışma süresini artırır; bu, kullanıcıların dosyalarına kesintisiz erişimi olduğu anlamına gelir.

Depolama kullanılabilirliğini gösteren diyagram.

Bunun dezavantajı, iç içe dayanıklılığın klasik iki yönlü yansıtmaya göre daha düşük kapasite verimliliğine sahip olmasıdır ve bu da biraz daha az kullanılabilir alan elde ettiğiniz anlamına gelir. Ayrıntılar için aşağıdaki Kapasite verimliliği bölümüne bakın.

Nasıl çalışır?

Bu bölüm, Depolama Alanları Doğrudan için iç içe geçmiş dayanıklılığın arka planını sağlar ve iki yeni dayanıklılık seçeneğini ve bunların kapasite verimliliğini açıklar.

İlham Kaynağı: RAID 5+1

RAID 5+1, iç içe dayanıklılığı anlamak için yararlı arka plan sağlayan yerleşik bir dağıtılmış depolama dayanıklılığı biçimidir. RAID 5+1'de, her sunucu içinde, tek bir sürücünün kaybına karşı korunmak için RAID-5 veya tek eşlik tarafından yerel dayanıklılık sağlanır. Daha sonra, iki sunucu arasındaki RAID-1 veya iki yönlü yansıtma tarafından iki sunucunun kaybına karşı koruma sağlamak için daha fazla dayanıklılık sağlanır.

RAID 5+1'i gösteren diyagram.

Dayanıklılık seçenekleri

Azure Stack HCI ve Windows Server'daki Depolama Alanları Doğrudan, özel RAID donanımına gerek kalmadan yazılımda uygulanan iki dayanıklılık seçeneği sunar:

  • İç içe iki yönlü ayna. Her sunucu içinde, iki yönlü yansıtma ile yerel dayanıklılık sağlanır ve ardından iki sunucu arasında iki yönlü yansıtma ile daha fazla dayanıklılık sağlanır. Temelde dört yönlü bir yansıtmadır ve her sunucuda farklı fiziksel disklerde bulunan iki kopya bulunur. İç içe iki yönlü yansıtma, ödün vermeyen performans sağlar: yazma işlemleri tüm kopyalara gider ve okumalar herhangi bir kopyadan gelir.

    İç içe iki yönlü yansıtmayı gösteren diyagram.

  • İç içe yansıtması hızlandırılmış eşlik. Önceki görüntüden iç içe iki yönlü yansıtmayı iç içe eşlik ile birleştirin. Her sunucuda, çoğu veri için yerel dayanıklılık, iki yönlü yansıtma kullanan yeni yazma işlemleri dışında tek bit düzeyinde eşlik aritmetiği tarafından sağlanır. Ardından, sunucular arasında iki yönlü yansıtma ile tüm veriler için daha fazla dayanıklılık sağlanır. Birime yapılan yeni yazma işlemleri, her sunucudaki ayrı fiziksel disklerde iki kopya içeren yansıtma bölümüne gider. Birimin yansıtma bölümü her sunucuda dolduğunda, en eski veriler dönüştürülür ve arka planda eşlik bölümüne kaydedilir. Sonuç olarak, her sunucu birimin verilerini iki yönlü yansıtmada veya tek bir eşlik yapısında içerir. Bu, yansıtması hızlandırılmış eşliğin çalışma şekline benzer; yansıtması hızlandırılmış eşlik için küme ve depolama havuzunda dört sunucu gerekir ve farklı bir eşlik algoritması kullanılır.

    İç içe yansıtması hızlandırılmış eşlik gösteren diyagram.

Kapasite verimliliği

Kapasite verimliliği, kullanılabilir alanın birim ayak izine oranıdır. Dayanıklılıkla ilgili kapasite ek yükünü açıklar ve seçtiğiniz dayanıklılık seçeneğine bağlıdır. Basit bir örnek olarak, verileri dayanıklılık olmadan depolamak %100 kapasite açısından verimlidir (1 TB veri 1 TB fiziksel depolama kapasitesini kaplar), iki yönlü yansıtma ise %50 verimlidir (1 TB veri 2 TB fiziksel depolama kapasitesini kaplar).

  • İç içe iki yönlü yansıtma her şeyin dört kopyasını yazar. Bu, 1 TB veri depolamak için 4 TB fiziksel depolama kapasitesine ihtiyacınız olduğu anlamına gelir. Basitliği cazip olsa da, iç içe iki yönlü aynanın kapasite verimliliği %25, Depolama Alanları Doğrudan dayanıklılık seçeneklerinden en düşük olandır.

  • İç içe yansıtması hızlandırılmış eşlik , iki faktöre bağlı olarak %35-40 civarında daha yüksek kapasite verimliliği sağlar: her bir sunucudaki kapasite sürücülerinin sayısı ve birim için belirttiğiniz yansıtma ve eşlik karışımı. Bu tablo, yaygın yapılandırmalar için bir arama sağlar:

    Sunucu başına kapasite sürücüleri %10 yansıtma %20 yansıtma %30 yansıtma
    4 35.7% 34.1% 32.6%
    5 37.7% 35.7% 33.9%
    6 39.1% 36.8% 34.7%
    7+ 40.0% 37.5% 35.3%

    Aşağıda tam matematik işleminin bir örneği verilmiştir. İki sunucunun her birinde altı kapasite sürücüsü olduğunu ve 10 GB yansıtma ve 90 GB eşlik içeren bir 100 GB birim oluşturmak istediğimizi varsayalım. Sunucu yerel çift yönlü yansıtma %50,0 verimlidir, yani 10 GB yansıtma verilerinin her sunucuda depolanması 20 GB sürer. Her iki sunucuya da yansıtılan toplam ayak izi 40 GB'tır. Bu durumda sunucu yerel tek eşliği %5/6 = %83,3 verimlidir, yani 90 GB eşlik verilerinin her sunucuda depolanması 108 GB sürer. Her iki sunucuya da yansıtılan toplam ayak izi 216 GB'tır. Bu nedenle toplam ayak izi [(10 GB / %50,0 + (%90 GB / %83,3] × 2 = 256 GB'tır ve toplam kapasite verimliliği %39,1'dir.

    Klasik iki yönlü yansıtma (%50) ve iç içe yansıtma hızlandırılmış eşliğin (%40'a kadar) kapasite verimliliğinin çok farklı olmadığını fark edin. Gereksinimlerinize bağlı olarak, biraz daha düşük kapasite verimliliği depolama kullanılabilirliğindeki önemli artışa değer olabilir. Birim başına dayanıklılık seçtiğinizden, aynı küme içinde iç içe dayanıklılık birimleriyle klasik iki yönlü yansıtma birimlerini karıştırabilirsiniz.

    İki yönlü yansıtma ile iç içe yansıtma hızlandırılmış eşlik arasındaki dengeyi gösteren diyagram.

İç içe dayanıklılık birimleri oluşturma

PowerShell'deki tanıdık depolama cmdlet'lerini kullanarak iç içe dayanıklı birimler oluşturabilirsiniz. Bu birimler aşağıdaki bölümde anlatılmaktadır.

1. Adım: Depolama katmanı şablonları oluşturma (yalnızca Windows Server 2019)

Windows Server 2019, birimleri oluşturmadan önce cmdlet'ini New-StorageTier kullanarak yeni depolama katmanı şablonları oluşturmanızı gerektirir. Bunu yalnızca bir kez yapmanız yeterlidir ve oluşturduğunuz her yeni birim bu şablonlara başvurabilir.

Not

Windows Server 2022, Azure Stack HCI 21H2 veya Azure Stack HCI 20H2 çalıştırıyorsanız bu adımı atlayabilirsiniz.

-MediaType Kapasite sürücülerinizin ve isteğe bağlı olarak -FriendlyName tercihinizi belirtin. Diğer parametreleri değiştirmeyin.

Örneğin, kapasite sürücüleriniz sabit disk sürücüleri (HDD) ise, PowerShell'i Yönetici olarak başlatın ve aşağıdaki cmdlet'leri çalıştırın.

NestedMirror katmanı oluşturmak için:

New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedMirrorOnHDD -ResiliencySettingName Mirror -MediaType HDD -NumberOfDataCopies 4

NestedParity katmanı oluşturmak için:

New-StorageTier -StoragePoolFriendlyName S2D* -FriendlyName NestedParityOnHDD -ResiliencySettingName Parity -MediaType HDD -NumberOfDataCopies 2 -PhysicalDiskRedundancy 1 -NumberOfGroups 1 -FaultDomainAwareness StorageScaleUnit -ColumnIsolation PhysicalDisk

Kapasite sürücüleriniz katı hal sürücüleri (SSD) ise bunun yerine olarak ayarlayın -MediaTypeSSD ve değerini -FriendlyName olarak *OnSSDdeğiştirin. Diğer parametreleri değiştirmeyin.

İpucu

Katmanların Get-StorageTier başarıyla oluşturulduğunu doğrulayın.

2. Adım: İç içe birimler oluşturma

cmdlet'ini New-Volume kullanarak yeni birimler oluşturun.

  • İç içe iki yönlü ayna

    İç içe iki yönlü yansıtmayı kullanmak için katman şablonuna NestedMirror başvurun ve boyutu belirtin. Örnek:

    New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume01 -StorageTierFriendlyNames NestedMirrorOnHDD -StorageTierSizes 500GB
    

    Kapasite sürücüleriniz katı hal sürücüleri (SSD) ise olarak değiştirin -StorageTierFriendlyNames*OnSSD.

  • İç içe yansıtması hızlandırılmış eşlik

    İç içe yansıtması hızlandırılmış eşlik kullanmak için hem ve NestedParity katman şablonlarına başvurun hem de birimin NestedMirror her bir bölümü için bir tane olmak üzere iki boyut belirtin (önce yansıtma, eşlik saniye). Örneğin, %20 iç içe iki yönlü yansıtma ve %80 iç içe eşlik olan bir 500 GB birim oluşturmak için şunu çalıştırın:

    New-Volume -StoragePoolFriendlyName S2D* -FriendlyName Volume02 -StorageTierFriendlyNames NestedMirrorOnHDD, NestedParityOnHDD -StorageTierSizes 100GB, 400GB
    

    Kapasite sürücüleriniz katı hal sürücüleri (SSD) ise olarak değiştirin -StorageTierFriendlyNames*OnSSD.

3. Adım: Windows Admin Center'da devam edin

İç içe dayanıklılık kullanan birimler, aşağıdaki ekran görüntüsünde olduğu gibi Windows Admin Center'da net etiketlemeyle gösterilir. Oluşturulduktan sonra, Depolama Alanları Doğrudan'deki diğer birimler gibi Windows Admin Center kullanarak bunları yönetebilir ve izleyebilirsiniz.

Windows Admin Center'de birim yönetimi.

İsteğe bağlı: Önbellek sürücülerine genişletme

Varsayılan ayarlarıyla iç içe dayanıklılık, aynı anda birden çok kapasite sürücüsünün veya aynı anda bir sunucu ve bir kapasite sürücüsünün kaybına karşı koruma sağlar. Bu korumayı önbellek sürücülerine genişletmek için dikkat edilmesi gereken bir nokta daha vardır: Önbellek sürücüleri genellikle birden çok kapasite sürücüsü için okuma ve yazma önbelleği sağladığından, diğer sunucu kapalı olduğunda önbellek sürücüsünün kaybını tolere edebilmenin tek yolu yazma işlemlerini önbelleğe almamaktır, ancak bu performansı etkiler.

Bu senaryoyu ele almak için Depolama Alanları Doğrudan, iki sunuculu kümedeki bir sunucu kapalıyken yazma önbelleğini otomatik olarak devre dışı bırakma ve sunucu yedeklendiğinde yazma önbelleğini yeniden etkinleştirme seçeneği sunar. Performans etkisi olmadan rutin yeniden başlatmalara izin vermek için, sunucu 30 dakika kapalı olana kadar yazma önbelleği devre dışı bırakılmaz. Yazma önbelleği devre dışı bırakıldıktan sonra yazma önbelleğinin içeriği kapasite cihazlarına yazılır. Bundan sonra, sunucu çevrimiçi sunucudaki başarısız bir önbellek cihazını tolere edebilir, ancak önbellekten okuma işlemi gecikebilir veya önbellek cihazı başarısız olursa başarısız olabilir.

Not

Tüm önbellek (tek medya türü) fiziksel sistemi için, iki sunuculu bir kümedeki bir sunucu kapalıyken yazma önbelleğini otomatik olarak devre dışı bırakmayı düşünmeniz gerekmez. Bunu yalnızca HDD kullanıyorsanız gerekli olan depolama veri yolu katmanı (SBL) önbelleğinde dikkate almanız gerekir.

(İsteğe bağlı) İki sunuculu kümedeki bir sunucu kapalıyken yazma önbelleğini otomatik olarak devre dışı bırakmak için PowerShell'i Yönetici olarak başlatın ve şunu çalıştırın:

Get-StorageSubSystem Cluster* | Set-StorageHealthSetting -Name "System.Storage.NestedResiliency.DisableWriteCacheOnNodeDown.Enabled" -Value "True"

True olarak ayarlandıktan sonra önbellek davranışı şu şekilde olur:

Durum Önbellek davranışı Önbellek sürücüsü kaybını tolere edebilir mi?
Her iki sunucu da çalışır durumda Önbellek okuma ve yazma işlemleri, tam performans Yes
Sunucu kapalı, ilk 30 dakika Önbellek okuma ve yazma işlemleri, tam performans Hayır (geçici olarak)
İlk 30 dakika sonra Yalnızca önbellek okuma sayısı, performans etkilendi Evet (önbellek kapasite sürücülerine yazıldıktan sonra)

Sık sorulan sorular

İç içe dayanıklılık hakkında sık sorulan soruların yanıtlarını bulun.

Mevcut bir birimi iki yönlü yansıtma ile iç içe dayanıklılık arasında dönüştürebilir miyim?

Hayır, birimler dayanıklılık türleri arasında dönüştürülemez. Azure Stack HCI, Windows Server 2022 veya Windows Server 2019'da yeni dağıtımlar için gereksinimlerinize en uygun dayanıklılık türünün hangisi olduğunu önceden belirleyin. Windows Server 2016'den yükseltiyorsanız, iç içe dayanıklılıkla yeni birimler oluşturabilir, verilerinizi geçirip eski birimleri silebilirsiniz.

Birden çok kapasite sürücüsü türüyle iç içe dayanıklılık kullanabilir miyim?

Evet, yukarıdaki 1. adım sırasında her katmanın değerini buna göre belirtmeniz yeter-MediaType. Örneğin, aynı kümedeki NVMe, SSD ve HDD ile NVMe önbellek sağlarken, ikinci ikisi kapasite sağlar: katmanı olarak -MediaType SSD ve NestedParity katmanı olarak -MediaType HDDayarlayınNestedMirror. Bu durumda eşlik kapasitesi verimliliği yalnızca HDD sürücü sayısına bağlıdır ve sunucu başına en az 4 sürücüye ihtiyacınız vardır.

Üç veya daha fazla sunucuyla iç içe dayanıklılık kullanabilir miyim?

Hayır, yalnızca kümenizde tam olarak iki sunucu varsa iç içe dayanıklılık kullanın.

İç içe dayanıklılık kullanmak için kaç sürücüye ihtiyacım var?

Depolama Alanları Doğrudan için gereken en az sürücü sayısı, sunucu düğümü başına dört kapasite sürücüsü ve sunucu düğümü başına iki önbellek sürücüsüdür (varsa). Bu, Windows Server 2016 değişmemiştir. İç içe dayanıklılık için başka bir gereksinim yoktur ve yedek kapasite önerisi de değişmemiştir.

İç içe dayanıklılık, sürücü değiştirmenin çalışma şeklini değiştirir mi?

Hayır.

İç içe dayanıklılık, sunucu düğümü değiştirmenin çalışma şeklini değiştirir mi?

Hayır. Sunucu düğümünü ve sürücülerini değiştirmek için şu sırayı izleyin:

  1. Giden sunucudaki sürücüleri devre dışı bırakma
  2. Yeni sunucuyu sürücüleriyle birlikte kümeye ekleme
  3. Depolama havuzu yeniden dengelenecek
  4. Giden sunucuyu ve sürücülerini kaldırma

Ayrıntılar için Sunucuları kaldırma makalesine bakın.

Sonraki adımlar