Aracılığıyla paylaş

SAP HANA Azure sanal makine depolama alanı yapılandırmaları

  • Makale

Azure, SAP HANA çalıştıran Azure VM'leri için uygun farklı depolama türleri sağlar. SAP HANA dağıtımları listesi için dikkate alınabilecek SAP HANA sertifikalı Azure depolama türleri:

Bu disk türleri hakkında bilgi edinmek için SAP iş yükü için Azure Depolama türleri ve Disk türü seçme makalesine bakın

Azure, Azure Standart ve premium depolama v1/v2 üzerinde VHD'ler için iki dağıtım yöntemi sunar. Azure blok depolama dağıtımları için Azure yönetilen disklerinden yararlanmanızı bekliyoruz.

IOPS ve depolama aktarım hızındaki depolama türlerinin ve bunların SLA'larının listesi için yönetilen diskler için Azure belgelerini gözden geçirin.

Önemli

Seçilen Azure depolama türünden bağımsız olarak, söz konusu depolamada kullanılan dosya sisteminin belirli işletim sistemi ve DBMS için SAP tarafından desteklenmesi gerekir. SAP destek notu #2972496 SAP HANA dahil olmak üzere farklı işletim sistemleri ve veritabanları için desteklenen dosya sistemlerini listeler. Bu, SAP HANA'nın her görev için okuma ve yazma için erişebileceği tüm birimler için geçerlidir. Özellikle SAP HANA için Azure'da NFS kullanıldığında, bu makalenin devamında belirtildiği gibi NFS sürümlerine yönelik ek kısıtlamalar uygulanır

Farklı depolama türleri için en düşük SAP HANA sertifikalı koşullar şunlardır:

  • Azure Premium Depolama v1 - /hana/log , Azure Yazma Hızlandırıcısı tarafından desteklenmelidir. /hana/veri birimi, Azure Yazma Hızlandırıcısı olmadan premium depolama v1'e veya Ultra diske yerleştirilebilir. Azure premium depolama v2 veya Azure premium SSD v2, Azure Write Accelerator kullanımını desteklemiyor
  • En azından /hana/log birimi için Azure Ultra disk. /hana/data birimi, Azure Write Accelerator olmadan premium depolama v1/v2'ye veya ultra diskin daha hızlı yeniden başlatma sürelerine ulaşmak için yerleştirilebilir
  • /hana/log ve /hana/data için Azure NetApp Files üzerinde NFS v4.1 birimleri. /hana/shared birimi NFS v3 veya NFS v4.1 protokollerini kullanabilir

Müşterilerle edindiğimiz deneyime bağlı olarak, /hana/data ve /hana/log arasında farklı depolama türlerini birleştirme desteğini değiştirdik. Azure NetApp Files tabanlı HANA VE NFS paylaşımları için sertifikalı farklı Azure blok depolamalarının kullanımını birleştirmek desteklenir. Örneğin, gerekli düşük gecikme süresini elde etmek için /hana/data'yı premium depolama v1 veya v2'ye yerleştirmek mümkündür ve /hana/log Ultra disk depolama alanına yerleştirilebilir. /hana/data için ANF'yi temel alan bir birim kullanıyorsanız, /hana/log birimi HANA sertifikalı Azure blok depolama türlerinden birine de yerleştirilebilir. Birimlerden biri (/hana/data gibi) için ANF'nin üzerinde NFS ve diğer birim için Azure premium depolama v1/v2 veya Ultra disk (/hana/log gibi) kullanılması desteklenir.

Şirket içi dünyada G/Ç alt sistemlerine ve özelliklerine nadiren önem vermek zorunda kaldınız. Bunun nedeni, alet satıcısının SAP HANA için en düşük depolama gereksinimlerinin karşılandığından emin olmasıydı. Azure altyapısını kendiniz oluştururken, sap tarafından verilen bu gereksinimlerin bazılarını bilmeniz gerekir. SAP'nin önerdiği en düşük aktarım hızı özelliklerinden bazıları şunlardır:

  • 1 MB G/Ç boyutlarıyla 250 MB/sn/sn/hana/günlükte okuma/yazma
  • /hana/data için 16 MB ve 64 MB G/Ç boyutları için en az 400 MB/sn okuma etkinliği
  • /hana/data için 16 MB ve 64 MB G/Ç boyutlarıyla en az 250 MB/sn yazma etkinliği

Düşük depolama gecikme süresinin DBMS sistemleri için kritik öneme sahip olduğu düşünüldüğünde, SAP HANA gibi DBMS verileri bellekte tutar. Depolamadaki kritik yol genellikle DBMS sistemlerinin işlem günlüğü yazma işlemlerinin etrafındadır. Ancak, kilitlenme kurtarmadan sonra kaydetme noktaları yazma veya bellek içi verileri yükleme gibi işlemler de kritik olabilir. Bu nedenle, /hana/data ve /hana/log birimleri için Azure premium depolama v1/v2, Ultra disk veya ANF kullanmak zorunlu olur.

HANA için depolama yapılandırmanızı seçmeye yönelik bazı yol gösterici ilkeler şöyle listelenebilir:

  • SAP iş yükü için Azure Depolama türlerine göre depolama türüne karar verin ve Disk türü seçin
  • Vm'yi boyutlandırırken veya belirlerken genel VM G/Ç aktarım hızı ve IOPS sınırları dikkate alınır. Genel VM depolama aktarım hızı bellek için iyileştirilmiş sanal makine boyutları makalesinde belgelenmiştir
  • Depolama yapılandırmasına karar verirken/hana/veri birimi yapılandırmanızla VM'nin genel aktarım hızının altında kalmaya çalışın. SAP HANA yazma kayıt noktaları, HANA agresif veren G/Ç olabilir. Kayıt noktası yazarken /hana/veri biriminizin aktarım hızı sınırlarına kadar kolayca gönderebilirsiniz. /hana/data birimini oluşturan diskleriniz VM'nizin izin verdiğinden daha yüksek bir aktarım hızına sahipse, kayıt noktası yazma tarafından kullanılan aktarım hızının yineleme günlüğü yazma işlem hızı taleplerini engellediği durumlarla karşılaşabilirsiniz. Uygulama aktarım hızını etkileyebilecek bir durum
  • HANA Sistem Çoğaltması kullanmayı düşünüyorsanız, her çoğaltmada /hana/data için kullanılan depolama alanı aynı olmalı ve her çoğaltmada /hana/log için kullanılan depolama türü aynı olmalıdır. Örneğin, bir VM ile /hana/data için Azure premium depolama v1 ve aynı HANA Sistem çoğaltma yapılandırmasının çoğaltmasını çalıştıran başka bir VM'de /hana/data için Azure Ultra disk kullanılması desteklenmez

Önemli

Bu veya sonraki belgelerdeki depolama yapılandırmaları için öneriler, başlangıç yönergeleri olarak amaçlanıyor. İş yükü çalıştırma ve depolama kullanım desenlerini analiz etme, sağlanan tüm depolama bant genişliğini veya IOPS'yi kullanmadığınızı fark edebilirsiniz. Daha sonra depolamada küçültmeyi düşünebilirsiniz. Aksi durumda, iş yükünüz bu yapılandırmalarda önerilenden daha fazla depolama aktarım hızına ihtiyaç duyabilir. Sonuç olarak daha fazla kapasite, IOPS veya aktarım hızı dağıtmanız gerekebilir. Gerekli depolama kapasitesi, gereken depolama gecikme süresi, depolama aktarım hızı ve IOPS gerekli ve en düşük maliyetli yapılandırma arasındaki gerilim alanında Azure, sizin ve HANA iş yükünüz için doğru güvenliğin aşılmasına yönelik doğru güvenliği bulmak ve ayarlamak için farklı özelliklere ve farklı fiyat noktalarına sahip yeterli sayıda farklı depolama türü sunar.

Şerit kümeleri ile SAP HANA veri birimi bölümleme karşılaştırması

Azure premium depolama v1'i kullanarak /hana/data ve/veya /hana/log hacmini birden çok Azure diskinde ayırdığınızda en iyi fiyat/performans oranına sahip olabilirsiniz. IOPS veya aktarım hızı konusunda daha fazlasını sağlayan daha büyük disk birimleri dağıtmak yerine. Birden çok Azure diskte tek bir birim oluşturmak, Linux'un parçası olan LVM ve MDADM birim yöneticileriyle gerçekleştirilebilir. Diskleri şeritleme yöntemi onlarca yıldır ve iyi bilinmektedir. Bu şeritli birimler, ihtiyaç duyabileceğiniz IOPS veya aktarım hızı özelliklerine ulaşmak kadar yararlı olsa da, bu şeritli birimleri yönetme konusunda karmaşıklıklar ekler. Özellikle birimlerin kapasite olarak uzatılmış olması gerektiğinde. EN azından /hana/data için SAP, birden çok Azure diskinde şerit oluşturma ile aynı hedefe ulaşan alternatif bir yöntem kullanıma sunulmuştur. SAP HANA 2.0 SPS03'ten bu yana, HANA dizin sunucusu G/Ç etkinliğini farklı Azure disklerinde bulunan birden çok HANA veri dosyası arasında ayırabiliyor. Bunun avantajı, farklı Azure disklerinde şeritli birim oluşturma ve yönetme işlemleriyle ilgilenmeniz gerekmeyecek olmasıdır. Veri birimi bölümlemenin SAP HANA işlevi, aşağıda ayrıntılı olarak açıklanmıştır:

Ayrıntıları gözden geçirerek, bu işlevin uygulanması birim yöneticisi tabanlı şerit kümelerinin karmaşıklıklarını ortadan kaldırıyor. Ayrıca HANA veri birimi bölümlemenin yalnızca Azure premium depolama v1/v2 gibi Azure blok depolama için çalışmadığını fark ediyorsunuz. Bu paylaşımların IOPS veya aktarım hızı sınırlamaları olması durumunda NFS paylaşımları arasında şerit açmak için de bu işlevi kullanabilirsiniz.

Linux G/Ç Zamanlayıcı modu

Linux'un birkaç farklı G/Ç zamanlama modu vardır. Linux satıcıları ve SAP aracılığıyla yaygın öneri, disk birimleri için G/Ç zamanlayıcısı modunu mq-deadline veya kyber modundan noop 'a (çok sıralı olmayan) veya SLES saptune profilleri tarafından henüz yapılmamışsa (çok sıralı olmayan) moda yeniden yapılandırmaktır. Ayrıntılara şu adreste başvurabilirsiniz:

Red Hat'te, ayarları farklı SAP uygulamaları için belirli ayar profilleri tarafından belirlenen şekilde bırakın.

Mantıksal birim yöneticileri kullanılırken şerit boyutları

Birkaç Azure premium diskte şerit kümeleri oluşturmak için LVM veya mdadm kullanıyorsanız şerit boyutlarını tanımlamanız gerekir. Bu boyutlar /hana/data ve /hana/log arasında farklılık gösterir. Öneri: Şerit boyutları olarak önerinin kullanılmasıdır:

  • /hana/data için 256 KB
  • /hana/log için 64 KB

Not

/hana/data için şerit boyutu, daha yeni Linux sürümleriyle müşteri deneyimlerine bağlı olarak 64 KB veya 128 KB çağrısı yapan önceki önerilerden 256 KB'a değiştirildi. 256 KB boyutu biraz daha iyi performans sağlıyor. Ayrıca daha büyük G/Ç boyutlarına sahip yeterli aktarım hızı elde etmek için /hana/log şerit boyutları önerisini 32 KB'tan 64 KB'a değiştirdik.

Not

Azure blok depolama alanı bir VHD'nin üç görüntüsü tuttuğundan RAID birimlerini kullanarak herhangi bir yedeklilik düzeyi yapılandırmanız gerekmez. Azure premium disklerle şerit kümesinin kullanımı yalnızca yeterli IOPS ve/veya G/Ç aktarım hızı sağlayan birimleri yapılandırmaktır.

Bir şerit kümesinin altında birden çok Azure diskini biriktirme, IOPS ve depolama aktarım hızı tarafında biriktirilir. Bu nedenle, 3 x P30 Azure premium depolama v1 diskleri arasında bir şerit kümesi koyarsanız, size tek bir Azure premium Depolama v1 P30 diskinin üç katı IOPS ve üç kat depolama aktarım hızı vermelidir.

Önemli

Birden çok Azure premium diskte şerit kümeleri oluşturmak için birim yöneticisi olarak LVM veya mdadm kullanıyorsanız, üç SAP HANA FileSystems /data, /log ve /shared varsayılan veya kök birim grubuna yerleştirilmemelidir. Genellikle /data, /log ve /shared için tek tek Birim Grupları oluşturmak üzere Linux Satıcıları yönergelerini izlemeniz kesinlikle önerilir.

HANA paylaşılan dosya sistemiyle ilgili dikkat edilmesi gerekenler

HANA dosya sistemleri boyutlandırılırken, çoğu veri ve günlük dosyası HANA sistemlerine dikkat edilir. Ancak/hana/shared, HANA ikili dosyaları gibi temel bileşenleri barındıran kararlı bir HANA sisteminin çalıştırılmasında da önemli bir rol oynar.
Büyük boyutluysa, /hana/shared aşırı okuma/yazma işlemleri nedeniyle G/Ç doygunluğuna neden olabilir. Örneğin, büyük bir döküm yazarken veya yoğun izleme sırasında ya da yedekleme /hana/paylaşılan dosya sistemine yazılırken. Gecikme süresi de artabilir.

HANA sistemi bir HA yapılandırmasındaysa, paylaşılan dosya sisteminden gelen yavaş yanıtlar (ör. /hana/shared) küme kaynaklarının zaman aşımlarına neden olabilir. HANA kaynak aracıları yanlışlıkla veritabanının kullanılabilir olmadığını varsayabileceğinden bu zaman aşımları gereksiz yük devretmelere neden olabilir.

/hana/paylaşılan önerilen boyutlar için SAP yönergeleri şöyle görünür:

Hacim Önerilen Boyut
/hana/paylaşılan ölçek artırma Min(1 TB, 1 x RAM)
/hana/paylaşılan ölçeği genişletme Çalışan düğümünün 1 x RAM'i
dört çalışan düğümü başına

Daha fazla ayrıntı için aşağıdaki SAP notlarına bakın:
3288971 - SSS: SAP HANA Sistem Çoğaltma Ortamlarında SUSE HAE/RedHat HAA Pacemaker Küme Kaynak Yöneticisi
1999930 - SSS: SAP HANA G/Ç Analizi

En iyi uygulama olarak performans sorunlarını önlemek için /hana/shared boyutunu belirleyin. İyi boyutlandırılmış /hana/paylaşılan dosya sisteminin, özellikle HA senaryolarında SAP HANA sisteminizin kararlılığı ve güvenilirliğine katkıda bulunduğunu unutmayın.

HANA için Azure Premium Depolama v1 yapılandırmaları

Azure premium depolama v1 kullanarak ayrıntılı HANA depolama yapılandırma önerileri için SAP HANA Azure sanal makinesi Premium SSD depolama yapılandırmaları belgesini okuyun.

HANA için Azure Premium SSD v2 yapılandırmaları

Azure premium ssd v2 depolama kullanarak ayrıntılı HANA depolama yapılandırma önerileri için SAP HANA Azure sanal makinesi Premium SSD v2 depolama yapılandırmaları belgesini okuyun.

SAP HANA için Azure Ultra disk depolama yapılandırması

Azure Ultra Disk kullanarak ayrıntılı HANA depolama yapılandırma önerileri için SAP HANA Azure sanal makinesi Ultra Disk depolama yapılandırmaları belgesini okuyun.

Azure NetApp Files'da NFS v4.1 birimleri

HANA için Azure NetApp Files hakkında ayrıntılı bilgi için SAP HANA için Azure NetApp Files'da NFS v4.1 birimleri belgesini okuyun.

Sonraki adımlar

Daha fazla bilgi için bkz.