SAP HANA için Azure NetApp Files üzerinde NFS v4.1 birimleri

  • Makale
  • Okumak için 11 dakika

Azure NetApp Files, /Hana/Shared, /Hana/Data ve /Hana/log birimleri için kullanılabilen yerel NFS paylaşımları sağlar. /Hana/Data ve /Hana/log birimleri IÇIN ANF tabanlı NFS paylaşımlarının KULLANıLMASı, v 4.1 NFS protokolünün kullanımını gerektirir. NFS Protokolü v3, paylaşımları ANF üzerinde dayandırırken /Hana/Data ve /Hana/log birimlerinin kullanımı için desteklenmez.

Önemli

Azure NetApp Files uygulanan NFS v3 protokolünün /Hana/Data ve /Hana/log için kullanılması desteklenmez. NFS 4,1 kullanımı, /Hana/Data ve /Hana/log birimleri için bir işlev noktasından bir görünüm açısından zorunludur. Öte yandan, /Hana/Shared BIRIMI için NFS v3 veya NFS v 4.1 protokolü, bir görünüm noktasından kullanılabilir.

Önemli noktalar

SAP NetWeaver ve SAP HANA için Azure NetApp Files düşünürken, aşağıdaki önemli noktalara dikkat edin:

  • En düşük kapasite havuzu 4 TiB 'dir
  • En küçük birim boyutu 100 GiB 'dir
  • Azure NetApp Files ve Azure NetApp Files birimlerinin bağlı olduğu tüm sanal makineler aynı bölgedeki aynı Azure sanal ağında veya eşlenmiş sanal ağlarda olmalıdır
  • Düşük gecikme süresi boyunca sanal makinelerin Azure NetApp depolama alanına yakın bir şekilde dağıtılmasını sağlamak önemlidir.
  • Seçilen sanal ağın bir alt ağı olmalıdır, Azure NetApp Files atanmış
  • Veritabanı sunucusundan ANF birimine gecikme süresinin ölçüldüğü ve 1 milisaniyenin altında olduğundan emin olun
  • Azure NetApp biriminin performansı, Azure NetApp Files Için hizmet düzeyindebelgelendiği gibi birim kotasının ve hizmet düzeyinin bir işlevidir. HANA Azure NetApp birimlerini boyutlandırdığınızda, elde edilen aktarım hızının HANA sistem gereksinimlerini karşıladığından emin olun. Alternatif olarak, birim kapasitesinin ve üretilen işin ayrı olarak yapılandırılabildiği ve ölçeklendiği bir El Ile QoS kapasite havuzu kullanmayı düşünün (SAP HANA belirli örnekler Bu belgede yer alabilir
  • Daha büyük bir birimde daha fazla performans elde etmek için "birleştirme" birimlerini deneyin. Örneğin,/sapmnt,/usr/SAP/Trans,... için bir birim kullanın. Mümkünse
  • Azure NetApp Files, dışarı aktarma ilkesisunar: izin verilen istemcileri, erişim türünü (okuma&yazma, salt okuma, vb.) denetleyebilirsiniz.
  • Azure NetApp Files Özellik henüz bölge farkında değildir. Şu anda Azure NetApp Files özelliği bir Azure bölgesindeki tüm kullanılabilirlik bölgelerinde dağıtılmaz. Bazı Azure bölgelerindeki olası gecikme etkilerine yönelik etkileri göz önünde bulundurun.
  • SIDadm IÇIN Kullanıcı kimliği ve sanal MAKINELERDEKI grup kimliği, sapsys Azure NetApp Files yapılandırma ile aynı olmalıdır.

Önemli

SAP HANA iş yükleri için düşük gecikme süresi kritik öneme sahiptir. Sanal makinelerin ve Azure NetApp Files birimlerinin yakın bir yerde dağıtıldığından emin olmak için Microsoft temsilcinizle birlikte çalışın.

Önemli

SIDadm Kullanıcı kimliği ve sapsys sanal makine Ile Azure NetApp YAPıLANDıRMASı arasındaki grup kimliği arasında UYUŞMAZLıK varsa, VM 'ye bağlanan Azure NetApp birimlerindeki dosyaların izinleri olarak görüntülenecektir nobody . sapsys Azure NetApp Files için Yeni bir sistem oluştururken, SID adm ve grup kimliği için doğru Kullanıcı kimliğini belirttiğinizden emin olun.

Azure NetApp Files HANA veritabanı için boyutlandırma

Bir Azure NetApp biriminin performansı, Azure NetApp Files Için hizmet düzeylerindebelgelendiği gibi birim boyutu ve hizmet düzeyi işlevindedir.

Anlaşılması gereken, boyutun ve hizmetin bir depolama uç noktası için fiziksel limitlerin olduğu performans ilişkisidir. Her depolama uç noktası, toplu oluşturma sırasında Azure NetApp Files atanmış alt ağa dinamik olarak eklenir ve bir IP adresi alır. Azure NetApp Files birimler: kullanılabilir kapasite ve dağıtım mantığına bağlı olarak, depolama uç noktası paylaşma

Aşağıdaki tabloda, yedeklemeleri depolamak için büyük bir "standart" birim oluşturmak ve tek bir birimin en fazla fiziksel bant genişliği kapasitesi aşılacağı için 12 TB 'den büyük bir "Ultra" birim oluşturmak mantıklı değildir.

Bir birim için en fazla yazma aktarım hızı ve tek bir Linux oturumu 1,2 ile 1,4 GB/sn arasındadır. /Hana/Data için daha fazla işleme ihtiyacınız varsa, veri yeniden yüklemesi sırasında g/ç etkinliğini veya birden çok NFS paylaşımındaki birden çok Hana veri dosyası üzerinde Hana işlemi 'i ayırmak için SAP HANA veri birimi bölümleme kullanabilirsiniz. Okuma aktarım hızını artırmak için NFS nConnect bağlama seçeneği kullanılabilir. Linux performansı ve nConnect Azure NetApp Files hakkında daha fazla bilgi için, Azure NetApp Files Için LINUX NFS bağlama seçenekleri en iyi uygulamalarımakalesini okuyun. HANA veri hacmi şeridi hakkında daha fazla bilgi için şu makaleleri okuyun:

Boyut Aktarım hızı standart Verimlilik Premium Verimlilik Ultra
1 TB 16 MB/sn 64 MB/sn 128 MB/sn
2 TB 32 MB/sn 128 MB/sn 256 MB/sn
4 TB 64 MB/sn 256 MB/sn 512 MB/sn
10 TB 160 MB/sn 640 MB/sn 1.280 MB/sn
15 TB 240 MB/sn 960 MB/sn 1.400 MB/sn1
20 TB 320 MB/sn 1.280 MB/sn 1.400 MB/sn1
40 TB 640 MB/sn 1.400 MB/sn1 1.400 MB/sn1

1: yazma veya tek oturum okuma üretilen iş sınırları (NFS bağlama seçeneği nConnect kullanılmıyor olması halinde)

Verilerin depolama arka ucunda aynı SSD 'ye yazıldığını anlamak önemlidir. Kapasite havuzundaki performans kotası, ortamı yönetebilmek için oluşturulmuştur. Depolama kpı 'ler tüm HANA veritabanı boyutları için eşittir. Neredeyse tüm durumlarda bu varsayım gerçekliği ve müşteri beklentisini yansıtmaz. HANA sistemlerinin boyutu, küçük bir sistemin depolama üretilen iş üretimi gerektirmesidir; büyük bir sistem yüksek depolama alanı işleme gerektirir. Ancak genel olarak daha büyük HANA veritabanı örnekleri için daha fazla verimlilik gereksinimi bekleyebilir. SAP 'nin temel alınan donanımla ilgili boyutlandırma kurallarının bir sonucu olarak, benzer HANA örnekleri de bir örnek yeniden başlatıldıktan sonra verileri yükleme gibi görevlerde daha fazla CPU kaynağı ve daha yüksek paralellik sağlar. Sonuç olarak, birim boyutları müşteri beklentileri ve gereksinimlerine benimsemelidir. Yalnızca saf kapasite gereksinimlerine göre değil.

SAP altyapısını Azure 'da tasarlarken, SAP tarafından en düşük işleme özelliklerine (üretimler sistemleri için) en düşük aktarım hızı özelliklerine çeviren bazı minimum depolama verimlilik gereksinimleri (üretim sistemleri için) farkında olmanız gerekir:

Birim türü ve g/ç türü SAP tarafından talep edilen en düşük KPI Premium hizmet düzeyi Ultra hizmet düzeyi
Günlük birimi yazma 250 MB/sn 4 TB 2 TB
Veri birimi yazma 250 MB/sn 4 TB 2 TB
Veri Hacmi Okuma 400 MB/sn 6,3 TB 3,2 TB

Üç KPI'nin de gerekli olması, /hana/veri hacminin en düşük okuma gereksinimlerini karşılamak için daha büyük kapasiteye doğru boyutlandır getirilmesi gerekir. El ile QoS kapasite havuzları kullanılırken birimlerin boyutu ve aktarım hızı bağımsız olarak tanımlanabilir. Hem kapasite hem de aktarım hızı aynı kapasite havuzundan alınarak havuzun hizmet düzeyi ve boyutu toplam performansı sunacak kadar büyük olmalı (örnek için buraya bakın)

Yüksek bant genişliği gerektirmeyen HANA sistemlerinde, ANF birim aktarım hızı daha küçük bir birim boyutuyla veya el ile QoS durumunda aktarım hızını doğrudan ayarlayarak düşürebilirsiniz. Bir HANA sisteminin daha fazla aktarım hızı gerektirdiğinde, birim, kapasiteyi çevrimiçi olarak yeniden boyutlandırmak tarafından uyarlanabilir. Yedekleme birimleri için KIP tanımlanmamıştır. Ancak yedekleme birimi aktarım hızı, iyi performans gösteren bir ortam için gereklidir. Günlük – ve Veri hacmi performansı müşteri beklentilerine göre tasarlanmalı.

Önemli

Tek bir NFS birimine dağıtan kapasiteden bağımsız olarak, aktarım hızının bir tüketici tarafından tek bir oturumda kullanılan 1,2-1,4 GB/sn bant genişliği aralığında yayla olması beklenir. Bunun ANF teklifinin temel mimarisi ve NFS ile ilgili Linux oturum sınırlarıyla ilgisi vardır. Azure NetApp Files için performans karşılaştırma testi sonuçları makalesinde belgelenmiş olan performans ve aktarım hızı sayıları, birden çok istemci VM'sine sahip paylaşılan bir NFS birimine ve birden çok oturumla sonuç olarak gerçekleştirildi. Bu senaryo, SAP'de ölçülen senaryodan farklıdır. Burada, NFS birimine karşı tek bir VM'den aktarım hızını ölçeriz. ANF üzerinde barındırıldı.

Veriler ve günlükler için SAP minimum aktarım hızı gereksinimlerini karşılamak ve /hana/shared yönergelerine göre önerilen boyutlar şöyle olabilir:

Birim Boyut
Premium Depolama katmanı		 Boyut
Ultra Depolama katmanı		 Desteklenen NFS protokolü
/hana/log/ 4 TiB 2 TiB v4.1
/hana/data 6.3 TiB 3.2 TiB v4.1
/hana/shared scale-up Min(1 TB, 1 x RAM) Min(1 TB, 1 x RAM) v3 veya v4.1
/hana/shared scale-out Çalışan düğümünün 1 x RAM'i
dört çalışan düğümü başına		 Çalışan düğümünün 1 x RAM'i
dört çalışan düğümü başına		 v3 veya v4.1
/hana/logbackup 3 x RAM 3 x RAM v3 veya v4.1
/hana/backup 2 x RAM 2 x RAM v3 veya v4.1

Tüm birimler için NFS v4.1 kesinlikle önerilir

Yedekleme birimlerinin boyutları tahmindir. Tam gereksinimler, iş yükü ve işlem süreçlerine göre tanımlanmalıdır. Yedeklemeler için, farklı örneklerde birden çok birimi SAP HANA daha düşük bir hizmet düzeyi ANF'ye sahip olan bir (veya iki) daha büyük birimlere birleştirebilirsiniz.

Not

Bu Azure NetApp Files belirtilen boyutlandırma önerileri, SAP'nin altyapı sağlayıcılarına yönelik minimum gereksinimleri hedeflemektedir. Gerçek müşteri dağıtımlarında ve iş yükü senaryolarında bu yeterli olmayacaktır. Bu önerileri başlangıç noktası olarak kullanın ve belirli iş yük gereksinimlerini temel alarak uyarlar.

Bu nedenle, AnF birimleri için Ultra disk depolama için zaten listelenmiş olan benzer aktarım hızını dağıtmayı düşünebilirsiniz. Ayrıca, ultra disk tablolarında zaten olduğu gibi farklı VM SKUS'ları için birimler için listelenen boyutları göz önünde bulundurabilirsiniz.

İpucu

Birimlere gerek kalmadan Azure NetApp Files dinamik olarak yeniden boyut oluşturabilir, sanal makineleri durdurabilir veya sanal unmount makineleri SAP HANA. Bu, hem beklenen hem de öngörülemeyen aktarım hızı taleplerini karşılamak için esneklik sağlar.

ANF'de barındırılan NFS v4.1 birimlerini kullanarak bekleme düğümüyle bir SAP HANA ölçek ölçeğini dağıtmaya ilişkin belgeler, SUSE LinuxEnterprise Server üzerinde Azure NetApp Files ile Azure VM'lerinde bekleme düğümüyle SAP HANA ölçeğini genişletin içinde yayımlanır.

Kullanılabilirlik

ANF sistem güncelleştirmeleri ve yükseltmeleri, müşteri ortamını etkilemeden uygulanır. Tanımlanan SLA %99,99'dır.

Birimler ve IP adresleri ve kapasite havuzları

ANF ile, temel alınan altyapının nasıl yerleşik olduğunu anlamak önemlidir. Kapasite havuzu yalnızca kapasite havuzu hizmet düzeyine göre kapasite ve performans bütçesi ile faturalama birimi sağlayan bir yapıdır. Kapasite havuzunun temel altyapıyla fiziksel ilişkisi yoktur. Hizmette bir birim oluşturulduğunda depolama uç noktası oluşturulur. Bir bire veri erişimi sağlamak için bu depolama uç noktasına tek bir IP adresi atanır. Birden fazla birim oluşturmanız, tüm birimlerin bu depolama uç noktasına bağlı olan temel çıplak filoya dağıtılmasını sağlar. ANF, yapılandırılan depolama biriminin birimleri veya/ve kapasitesi iç önceden tanımlanmış bir düzeye ulaştığında müşteri iş yüklerini otomatik olarak dağıtan bir mantığa sahiptir. Yeni bir IP adresine sahip yeni bir depolama uç noktasının birimlere erişmek için otomatik olarak oluşturularak bu tür durumlar olduğunu fark edersiniz. ANF hizmeti, bu dağıtım mantığı üzerinde müşteri denetimi sağlamaz.

Günlük birimi ve günlük yedekleme birimi

Çevrimiçi yenidendo günlüğünü yazmak için "günlük birimi" ( /hana/log) kullanılır. Bu nedenle, bu birde bulunan açık dosyalar vardır ve bu birimin anlık görüntüsünün açılması mantıklı olmaz. Çevrimiçi yenidendo günlük dosyaları, çevrimiçi yenidendo günlük dosyası dolduktan veya bir yeniden yürütme günlüğü yedeklemesi yürütülürken arşivlenir veya günlük yedekleme birimine yedeklenir. Makul yedekleme performansı sağlamak için günlük yedekleme birimi iyi bir aktarım hızı gerektirir. Depolama maliyetlerini iyileştirmek için birden çok HANA örneğinin günlük yedekleme birimini birleştirmek mantıklı olabilir. Böylece birden çok HANA örneği aynı birimi kullanır ve yedeklerini farklı dizinlere yazar. Bu tür bir birleştirmeyi kullanarak daha fazla aktarım hızı elde etmek için birimi biraz daha büyütebilirsiniz.

Aynı durum, tam HANA veritabanı yedeklemelerini yazmak için kullanmakta olduğu birim için de geçerlidir.
 

Backup

Azure Sanal Makineler'de SAP HANA için yedekleme kılavuzu makalesinde açıklandığı gibi akış yedeklemeleri ve SAP HANA veritabanlarını yedeklemeninyanı sıra, Azure NetApp Files depolama tabanlı anlık görüntü yedeklemeleri gerçekleştirme olasılığını da açar.

SAP HANA şunları destekler:

  • Depolama 1.0 SPS7 ve üzerine sahip tek bir kapsayıcı sistemi için SAP HANA tabanlı anlık görüntü yedekleme desteği
  • Depolama 2.0 SPS1 ve üzerine sahip tek bir kiracıya sahip Çoklu Veritabanı Kapsayıcısı (MDC) HANA ortamları için SAP HANA tabanlı anlık görüntü yedekleme desteği
  • Depolama 2.0 SPS4 ve üzerine sahip birden çok kiracıya sahip Çoklu Veritabanı Kapsayıcısı (MDC) HANA ortamları için SAP HANA tabanlı anlık görüntü yedekleme desteği

Depolama tabanlı anlık görüntü yedeklemeleri oluşturmak dört adımlı basit bir yordamdır.

  1. HANA (iç) veritabanı anlık görüntüsü oluşturma - sizin veya araçların gerçekleştirmesi gereken bir etkinlik
  2. SAP HANA tutarlı bir durum oluşturmak için verileri veri dosyalarına yazar- HANA, HANA anlık görüntüsü oluşturma işleminin sonucu olarak bu adımı gerçekleştirir
  3. Depolamada /hana/data birimi üzerinde anlık görüntü oluşturun; sizin veya araçların gerçekleştirmesi gereken bir adımdır. /hana/günlük birimi üzerinde anlık görüntü gerçekleştirmeye gerek yoktur
  4. HANA (iç) veritabanı anlık görüntüsünü silin ve normal işlemi sürdürün. Sizin veya araçların gerçekleştirmesi gereken bir adımdır

Uyarı

Son adımın eksik olduğu veya son adımın gerçekleştirilene kadar başarısız olduğu, SAP HANA bellek talebi üzerinde ciddi bir etkisi vardır ve bu da performansın SAP HANA

BACKUP DATA FOR FULL SYSTEM CREATE SNAPSHOT COMMENT 'SNAPSHOT-2019-03-18:11:00';

SAP HANA için ANF anlık görüntü yedeklemesi

az netappfiles snapshot create -g mygroup --account-name myaccname --pool-name mypoolname --volume-name myvolname --name mysnapname

SAP HANA bölüm2 için ANF anlık görüntü yedeklemesi

BACKUP DATA FOR FULL SYSTEM CLOSE SNAPSHOT BACKUP_ID 47110815 SUCCESSFUL SNAPSHOT-2020-08-18:11:00';

Bu anlık görüntü yedekleme yordamı çeşitli araçlar kullanılarak çeşitli yollarla yönetilebilir. Bunun bir örneği, ntaphana_azure.py" python betiğidir GitHub Bu, herhangi bir bakım veya destek olmadan "olduğu gibi" sağlanan örnek https://github.com/netapp/ntaphana koddur.

Dikkat

Anlık görüntü kendi içinde korumalı bir yedekleme değildir çünkü anlık görüntüsünü az önce alan birim ile aynı fiziksel depolamada bulunur. Günlük en az bir anlık görüntüyü farklı bir konuma "korumak" zorunludur. Bu işlem aynı ortamda, uzak bir Azure bölgesinde veya Azure Blob depolama alanında yapılabilir.

Depolama anlık görüntüsü tabanlı uygulamayla tutarlı yedekleme için kullanılabilir çözümler:

  • Microsoft Azure Uygulamayla Tutarlı Anlık Görüntü aracı (AzAcSnap), depolama anlık görüntüsü almadan önce bunları uygulamayla tutarlı bir duruma koymak için gereken tüm düzenlemeyi işerek üçüncü taraf veritabanları için veri korumasını sağlayan bir komut satırı aracıdır ve ardından bunları işletimsel duruma döndürür. AzAcSnap, HEM HANA Büyük Örneği için anlık görüntü tabanlı yedeklemeleri hem de Azure NetApp Files. Daha fazla bilgi için bkz. Azure Uygulamayla Tutarlı Anlık Görüntü aracı nedir?
  • Commvault yedekleme ürünlerinin kullanıcıları için bir diğer seçenek de Commvault IntelliSnap V.11.21 ve sonraki bir seçenektir. Commvault'un bu veya sonraki sürümleri, Azure NetApp Files desteği sağlar. Commvault IntelliSnap 11.21 makalesi daha fazla bilgi sağlar.

Azure blob depolama kullanarak anlık görüntüyü yedekleme

Azure blob depolamaya yedekleme, ANF tabanlı HANA veritabanı depolama anlık görüntüsü yedeklemelerini kaydetmenin uygun maliyetli ve hızlı bir yöntemidir. Anlık görüntüleri Azure Blob depolamaya kaydetmek için AzCopy aracı tercih edilir. Bu aracın en son sürümünü indirin ve örneğin, GitHub'den python betiği yüklü olan bin dizinine yükleyin. En son AzCopy aracını indirin:

root # wget -O azcopy_v10.tar.gz https://aka.ms/downloadazcopy-v10-linux && tar -xf azcopy_v10.tar.gz --strip-components=1
Saving to: ‘azcopy_v10.tar.gz’

En gelişmiş özellik SYNC seçeneğidir. SYNC seçeneğini kullanırsanız, azcopy kaynağı ve hedef dizini eşitler. --delete-destination parametresinin kullanımı önemlidir. Bu parametre olmadan, azcopy hedef sitedeki dosyaları slanmaz ve hedef tarafındaki alan kullanımı büyür. Azure depolama hesabınızla bir Blok Blobu kapsayıcısı oluşturun. Ardından blob kapsayıcısı için SAS anahtarını oluşturun ve snapshot klasörünü Azure Blob kapsayıcısı ile eşitler.

Örneğin, verileri korumak için günlük bir anlık görüntü Azure blob kapsayıcısı ile eşitlenecekse. Yalnızca bir anlık görüntü tutulmalıdır ve aşağıdaki komut kullanılabilir.

root # > azcopy sync '/hana/data/SID/mnt00001/.snapshot' 'https://azacsnaptmytestblob01.blob.core.windows.net/abc?sv=2021-02-02&ss=bfqt&srt=sco&sp=rwdlacup&se=2021-02-04T08:25:26Z&st=2021-02-04T00:25:26Z&spr=https&sig=abcdefghijklmnopqrstuvwxyz' --recursive=true --delete-destination=true

Sonraki adımlar

Makaleyi okuyun: