SAP HANA için Azure NetApp Files üzerinde NFS v4.1 birimleri
Azure NetApp Files, /hana/shared, /hana/data ve /hana/log birimleri için kullanılabilecek yerel NFS paylaşımları sağlar. /hana/data ve /hana/log birimleri için ANF tabanlı NFS paylaşımlarının kullanılması v4.1 NFS protokolünün kullanımını gerektirir. NFS protokolü v3, ANF'de paylaşımları temel alırken /hana/data ve /hana/log birimlerinin kullanımı için desteklenmez.
Önemli
Azure NetApp Files üzerinde uygulanan NFS v3 protokollerinin /hana/data ve /hana/log için kullanılması desteklenmez. İşlevsel bir bakış açısından /hana/data ve /hana/log birimleri için NFS 4.1 kullanımı zorunludur. /hana/shared birimi için ise NFS v3 veya NFS v4.1 protokolü işlevsel bir bakış açısından kullanılabilir.
Dikkat edilmesi gereken önemli hususlar
SAP Netweaver ve SAP HANA için Azure NetApp Files'ı göz önünde bulundurarak aşağıdaki önemli noktalara dikkat edin:
En düşük kapasite havuzu 4 TiB'dir
En düşük birim boyutu 100 GiB'dir
ANF tabanlı NFS paylaşımları ve bu paylaşımları bağlayan sanal makineler aynı Azure Sanal Ağ veya aynı bölgedeki eşlenmiş sanal ağlarda olmalıdır
Seçilen sanal ağın Azure NetApp Files'a atanmış bir alt ağı olmalıdır. SAP iş yükü için, ANF'ye temsilci olarak atanan alt ağ için /25 aralığının yapılandırılması kesinlikle önerilir.
Sanal makinelerin Azure NetApp depolama alanına yeterli yakınlığı dağıtarak daha düşük gecikme süresine sahip olması önemlidir; örneğin, SAP HANA tarafından yineleme günlüğü yazma işlemleri için talep edilir.
- Bu arada Azure NetApp Files, NFS birimlerini belirli Azure Kullanılabilirlik Alanları dağıtma işlevine sahiptir. Böyle bir bölgesel yakınlık, çoğu durumda 1 milisaniyenin altında bir gecikme süresi elde etmek için yeterli olacaktır. İşlev genel önizleme aşamasındadır ve Azure NetApp Files için kullanılabilirlik alanı birim yerleşimini yönetme makalesinde açıklanmıştır. Bu işlevsellik, VM'nizle ayırdığınız NFS birimleri arasında yakınlık elde etmek için Microsoft ile herhangi bir etkileşimli işlem gerektirmez.
- En uygun yakınlığı elde etmek için Uygulama Birim Gruplarının işlevselliği kullanılabilir. Bu işlevsellik yalnızca en uygun yakınlığı aramakla kalmaz, aynı zamanda NFS birimlerinin en uygun yerleşimi için de geçerlidir, dolayısıyla HANA verileri ve yineleme günlüğü birimleri farklı denetleyiciler tarafından işlenir. Dezavantajı, bu yöntemin VM'lerinizi sabitlemek için Microsoft ile bazı etkileşimli işlemlere ihtiyacı olmasıdır.
Veritabanı sunucusundan ANF birimine olan gecikme süresinin 1 milisaniyenin altında ölçülmüş olduğundan emin olun
Azure NetApp biriminin aktarım hızı, Azure NetApp Files için Hizmet düzeyi bölümünde belirtildiği gibi birim kotasının ve Hizmet düzeyinin bir işlevidir. HANA Azure NetApp birimlerini boyutlandırırken elde edilen aktarım hızının HANA sistem gereksinimlerini karşıladığından emin olun. Alternatif olarak, birim kapasitesinin ve aktarım hızının bağımsız olarak yapılandırılıp ölçeklendirilebileceği el ile QoS kapasite havuzu kullanmayı göz önünde bulundurun (SAP HANA'ya özgü örnekler bu belgede verilmiştir
Daha büyük bir Birimde daha fazla performans elde etmek için birimleri "birleştirmeyi" deneyin, örneğin,/sapmnt, /usr/sap/trans, ... için bir birim kullanın. mümkünse
Azure NetApp Files dışarı aktarma ilkesi sunar: İzin verilen istemcileri, erişim türünü (Okuma ve Yazma, Salt Okunur vb.) denetleyebilirsiniz.
Sidadm kullanıcı kimliği ve sanal makinelerde için
sapsysGrup Kimliği, Azure NetApp Files'daki yapılandırmayla eşleşmelidir.SAP not 3024346 belirtilen Linux işletim sistemi parametrelerini uygulama
Önemli
SAP HANA iş yükleri için düşük gecikme süresi kritik öneme sahiptir. Sanal makinelerin ve Azure NetApp Files birimlerinin birbirine yakın bir şekilde dağıtıldığından emin olmak için Microsoft temsilcinizle birlikte çalışın.
Önemli
Sid adm kullanıcı kimliği ile sanal makine ile Azure NetApp yapılandırması arasındaki Grup Kimliği sapsys arasında bir uyuşmazlık varsa, VM'ye bağlanan Azure NetApp birimlerindeki dosyaların izinleri olarak nobodygörüntülenir. Azure NetApp Files'a yeni bir sistem eklerken sidadm için doğru Kullanıcı Kimliğini ve için sapsysGrup Kimliğini belirttiğinizden emin olun.
NCONNECT bağlama seçeneği
Nconnect, ANF'de barındırılan NFS birimleri için NFS istemcisinin tek bir NFS biriminde birden çok oturum açmasına olanak tanıyan bir bağlama seçeneğidir. Nconnect değerinin 1'den büyük bir değerle kullanılması, NFS istemcisini konuk işletim sistemi ile bağlı NFS birimleri arasındaki trafiği işlemek için istemci tarafında (konuk işletim sisteminde) birden fazla RPC oturumu kullanması için de tetikler. Bir NFS biriminin trafiğini işleyen birden çok oturumun kullanımı, ancak aynı zamanda birden çok RPC oturumunun kullanımı aşağıdaki gibi performans ve aktarım hızı senaryolarını ele alabilir:
- Bir VM'de farklı hizmet düzeylerine sahip birden çok ANF barındırılan NFS birimi bağlama
- Bir birim ve tek bir Linux oturumu için en yüksek yazma aktarım hızı 1,2 ile 1,4 GB/sn arasındadır. Bir ANF barındırılan NFS biriminde birden çok oturum olması aktarım hızını artırabilir
Nconnect'i bağlama seçeneği olarak destekleyen Linux işletim sistemi sürümleri ve özellikle farklı NFS sunucu uç noktalarıyla nconnect ile ilgili bazı önemli yapılandırma konuları için, Azure NetApp Files için Linux NFS bağlama seçenekleri en iyi yöntemleri belgesini okuyun.
Azure NetApp Files üzerinde HANA veritabanı için boyutlandırma
Azure NetApp biriminin aktarım hızı, Azure NetApp Files için Hizmet düzeyleri bölümünde belirtildiği gibi birim boyutunun ve Hizmet düzeyinin bir işlevidir.
Anlaşılması gereken önemli nokta, boyutun performans ilişkisidir ve hizmetin depolama uç noktası için fiziksel sınırlar vardır. Her depolama uç noktası, birim oluşturma işleminden sonra Azure NetApp Files temsilci alt ağına dinamik olarak eklenir ve bir IP adresi alır. Azure NetApp Files birimleri kullanılabilir kapasiteye ve dağıtım mantığına bağlı olarak bir depolama uç noktasını paylaşabilir
Aşağıdaki tabloda, yedeklemeleri depolamak için büyük bir "Standart" birim oluşturmanın mantıklı olabileceği ve tek bir birimin maksimum fiziksel bant genişliği kapasitesi aşılacağı için 12 TB'tan büyük bir "Ultra" birimi oluşturmanın mantıklı olmadığı gösterilmiştir.
/hana/veri biriminiz için tek bir Linux oturumunun sağlayabileceklerinden daha fazla yazma aktarım hızına ihtiyacınız varsa, alternatif olarak SAP HANA veri birimi bölümleme özelliğini de kullanabilirsiniz. SAP HANA veri birimi bölümleme, birden çok NFS paylaşımında bulunan birden çok HANA veri dosyası arasında veri yeniden yükleme veya HANA kayıt noktaları sırasında G/Ç etkinliğinin şeritlerini oluşturur. HANA veri hacmi şeritleme hakkında daha fazla bilgi için şu makaleleri okuyun:
- HANA Yönetici istrator Kılavuzu
- SAP HANA hakkında blog - Veri Birimlerini Bölümleme
- SAP Notu #2400005
- SAP Notu #2700123
| Size | Aktarım Hızı Standardı | Aktarım Hızı Premium | İşleme Hızı 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 aktarım hızı sınırları (NFS bağlama seçeneği nconnect kullanılmamışsa)
Verilerin depolama arka uçtaki aynı SSD'lere yazıldığını anlamak önemlidir. Ortamı yönetebilmek için kapasite havuzundan performans kotası oluşturuldu. Depolama KPI'leri tüm HANA veritabanı boyutları için eşittir. Neredeyse her durumda, bu varsayım gerçekliği ve müşteri beklentisini yansıtmaz. HANA Sistemlerinin boyutu, küçük bir sistemin düşük depolama aktarım hızı gerektirdiği ve büyük bir sistemin yüksek depolama aktarım hızı gerektirdiği anlamına gelmez. Ancak genellikle daha büyük HANA veritabanı örnekleri için daha yüksek aktarım hızı gereksinimleri beklenebilir. Daha büyük HANA örnekleri gibi temel alınan donanımlar için SAP boyutlandırma kurallarının bir sonucu olarak, örnekler yeniden başlatıldıktan sonra verileri yükleme gibi görevlerde daha fazla CPU kaynağı ve daha yüksek paralellik de sağlar. Sonuç olarak birim boyutları müşteri beklentilerine ve gereksinimlerine göre benimsenmelidir. Yalnızca saf kapasite gereksinimleriyle değil.
Azure'da SAP altyapısını tasarladığınızda SAP tarafından sağlanan bazı minimum depolama aktarım hızı gereksinimlerinin (üretim Sistemleri için) farkında olmanız gerekir. Bu gereksinimler aşağıdakilerin en düşük aktarım hızı özelliklerine dönüşür:
| 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 Birimi Okuma | 400 MB/sn | 6,3 TB | 3,2 TB |
Üç KPI'nin de talep edilmesi nedeniyle, /hana/veri hacminin en düşük okuma gereksinimlerini karşılamak için daha büyük kapasiteye doğru boyutlandırılması gerekir. El ile QoS kapasite havuzları kullanıyorsanız, 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ındığından, havuzun hizmet düzeyi ve boyutu toplam performansı sunabilecek kadar büyük olmalıdır (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 kullanılarak aktarım hızını doğrudan ayarlayarak düşürülebilir. Bir HANA sisteminin daha fazla aktarım hızı gerektirmesi durumunda, kapasite çevrimiçi olarak yeniden boyutlandırılarak birim uyarlanabilir. Yedekleme birimleri için hiçbir KPI tanımlanmamıştır. Ancak, iyi performans gösteren bir ortam için yedekleme birimi aktarım hızı gereklidir. Günlük – ve Veri hacmi performansı müşteri beklentilerine göre tasarlanmalıdır.
Önemli
Tek bir NFS birimine dağıttığınız 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 olması beklenir. Bunun, ANF teklifinin temel mimarisi ve NFS ile ilgili Linux oturum sınırlarıyla ilgili olması gerekir. Azure NetApp Files için performans karşılaştırma testi sonuçları makalesinde belirtildiği gibi performans ve aktarım hızı numaraları, birden çok istemci VM'si olan bir paylaşılan NFS biriminde ve bunun sonucunda birden çok oturumla gerçekleştirilir. Bu senaryo, SAP'de ölçtük senaryoya göre farklıdır. Burada tek bir VM'den NFS birimine göre aktarım hızını ölçeriz. ANF'de barındırılan.
Veri ve günlük için SAP minimum aktarım hızı gereksinimlerini karşılamak ve /hana/shared yönergelerine göre önerilen boyutlar şöyle görünür:
| Hacim | Size Premium Depolama katmanı |
Size 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/paylaşılan ölçek artırma | Min(1 TB, 1 x RAM) | Min(1 TB, 1 x RAM) | v3 veya v4.1 |
| /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 |
Ç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.
/hana/shared boyutunun dikkate alınması gereken noktaları dikkatle gözden geçirin; uygun boyutlandırılmış /hana/paylaşılan birim sistemin kararlılığında katkıda bulunur.
Yedekleme birimlerinin boyutları tahminlerdir. İş yükü ve işlem süreçlerine göre tam gereksinimlerin tanımlanması gerekir. Yedeklemeler için, farklı SAP HANA örnekleri için birçok birimi bir (veya iki) daha büyük birimde bir araya getirebilirsiniz ve bu da daha düşük hizmet düzeyi ANF'ye sahip olabilir.
Not
Bu belgede belirtilen Azure NetApp Files, boyutlandırma önerileri SAP'nin altyapı sağlayıcılarına yönelik en düşük gereksinimleri hedeflemektedir. Gerçek müşteri dağıtımlarında ve iş yükü senaryolarında bu yeterli olmayabilir. Bu önerileri başlangıç noktası olarak kullanın ve belirli iş yükünüzün gereksinimlerine göre uyarlayın.
Bu nedenle ANF birimleri için Ultra disk depolama için listelenen aktarım hızının benzerini dağıtmayı göz önünde bulundurabilirsiniz. Ayrıca, ultra disk tablolarında olduğu gibi farklı VM SKU'ları için birimler için listelenen boyutları da göz önünde bulundurun.
İpucu
Azure NetApp Files birimlerini dinamik olarak yeniden boyutlandırabilir, birimlere unmount gerek kalmadan sanal makineleri durdurabilir veya SAP HANA'yı durdurabilirsiniz. Bu, uygulamanızın hem beklenen hem de öngörülemeyen aktarım hızı taleplerini karşılama esnekliği sağlar.
ANF tabanlı NFS v4.1 birimlerini kullanarak bekleme düğümü ile SAP HANA ölçeği genişletme yapılandırması dağıtma belgeleri, SUSE Linux Enterprise Server üzerinde Azure NetApp Files ile Azure VM'lerinde bekleyen düğüm ile SAP HANA ölçeği genişletmede yayımlanır.
Linux Çekirdeği Ayarlar
SAP HANA'yı ANF'ye başarıyla dağıtmak için Linux çekirdek ayarlarının SAP not 3024346 göre uygulanması gerekir.
Pacemaker ve Azure Load Balancer kullanan Yüksek Kullanılabilirlik (HA) kullanan sistemler için /etc/sysctl.d/91-NetApp-HANA.conf dosyasında aşağıdaki ayarların uygulanması gerekir
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1
Pacemaker ve Azure Load Balancer olmadan çalışan sistemler /etc/sysctl.d/91-NetApp-HANA.conf içinde bu ayarları uygulamalıdır
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 131072 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
net.core.netdev_max_backlog = 300000
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
Bölgesel yakınlık ile dağıtım
NFS birimlerinizin ve VM'lerinizin bölgesel yakınlık düzeyini elde etmek için Azure NetApp Files için kullanılabilirlik alanı birim yerleşimini yönetme başlığında açıklandığı gibi yönergeleri izleyebilirsiniz. Bu yöntemle, VM'ler ve NFS birimleri aynı Azure Kullanılabilirlik Alanı'nda olur. Azure bölgelerinin çoğunda bu yakınlık türü, SAP HANA için daha küçük yineleme günlüğü yazma işlemleri için 1 milisaniyeden daha az gecikme süresi elde etmek için yeterli olmalıdır. Bu yöntem, VM'leri belirli bir veri merkezine yerleştirmek ve sabitlemek için Microsoft ile herhangi bir etkileşimli çalışma gerektirmez. Sonuç olarak, dağıtmış olduğunuz Kullanılabilirlik Alanı'nda sunulan tüm VM türleri ve aileleri içindeki VM boyutlarını ve ailelerini değiştirme konusunda esnek olursunuz. Böylece, avize koşullarında esnek tepki verebilir veya daha düşük maliyetli VM boyutlarına veya ailelerine daha hızlı ilerleyebilirsiniz. 1 milisaniyeye yakın yineleme günlüğü gecikme süreleriyle çalışabilen üretim dışı sistemler ve üretim sistemleri için bu yöntemi öneririz. İşlev şu anda genel önizleme aşamasındadır.
SAP HANA (AVG) için Azure NetApp Files uygulama birimi grubu aracılığıyla dağıtım
ANF birimlerini VM'nize yakın bir şekilde dağıtmak için SAP HANA (AVG) için Azure NetApp Files uygulama birimi grubu adlı yeni bir işlev geliştirilmiştir. İşlevselliği belgeleyen bir dizi makale vardır. En iyisi SAP HANA için Azure NetApp Files uygulama birimi grubunu anlama makalesiyle başlamaktır. Makaleleri okurken, AVG'lerin kullanımının Azure yakınlık yerleştirme gruplarının kullanımını da içerdiği netleşir. Yakınlık yerleştirme grupları, oluşturulan birimlere bağlanmak için yeni işlevler tarafından kullanılır. HANA sisteminin kullanım ömrü boyunca VM'lerin ANF birimlerinden taşınmamasını sağlamak için, dağıttığınız bölgelerin her biri için Avset/PPG birleşimini kullanmanızı öneririz. Dağıtım sırası şöyle görünür:
- Vm'lerin taşınmamasını sağlamak için boş AvSet'in bir işlem HW'sine sabitlemesini istemeniz gereken formu kullanarak
- Kullanılabilirlik Kümesine bir PPG atayın ve bu Kullanılabilirlik Kümesine atanmış bir VM'yi başlatın
- HANA birimlerinizi dağıtmak için SAP HANA işlevselliği için Azure NetApp Files uygulama birimi grubunu kullanma
AVG'leri en uygun şekilde kullanmak için yakınlık yerleştirme grubu yapılandırması şöyle görünür:
Diyagramda DBMS katmanı için bir Azure yakınlık yerleştirme grubu kullanacağınız gösterilmektedir. Böylece AVG'lerle birlikte kullanılabilir. Yakınlık yerleştirme grubuna yalnızca HANA örneklerini çalıştıran VM'leri dahil etmek en iyisidir. AVG'nin ANF donanımına en yakın yakınlığı belirlemesi için tek bir HANA örneğine sahip tek bir VM kullanılsa bile yakınlık yerleştirme grubu gereklidir. Ayrıca, ANF'de NFS birimini NFS birimlerini kullanan VM'lere mümkün olduğunca yakın bir şekilde ayırmak için.
Bu yöntem, düşük gecikme süresiyle ilgili olarak en uygun sonuçları oluşturur. Yalnızca NFS birimlerini ve VM'leri mümkün olduğunca birbirine yaklaştırarak değil. Ancak NetApp arka ucundaki farklı denetleyiciler arasında verileri yerleştirme ve günlük birimlerini yineleme konuları da dikkate alınır. Ancak, dezavantajı VM dağıtımınızın bir veri merkezine sabitlenmiş olmasıdır. Bu da VM türlerini ve ailelerini değiştirme esnekliğini kaybediyor. Sonuç olarak, bu yöntemi bu kadar düşük depolama gecikme süresi gerektiren sistemlerle sınırlamanız gerekir. Diğer tüm sistemler için, vm ve ANF'nin geleneksel bölgesel dağıtımıyla dağıtımı denemeniz gerekir. Çoğu durumda bu düşük gecikme süresi açısından yeterlidir. Bu ayrıca VM ve ANF'nin bakımı ve yönetiminin kolay olmasını sağlar.
Kullanılabilirlik
ANF sistem güncelleştirmeleri ve yükseltmeleri müşteri ortamını etkilemeden uygulanır. Tanımlanan SLA %99,99'dur.
Birimler, IP adresleri ve kapasite havuzları
ANF ile, temel alınan altyapının nasıl oluşturulduğunun anlaşılması ö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 alınan altyapıyla fiziksel ilişkisi yoktur. Hizmette birim oluşturduğunuzda bir depolama uç noktası oluşturulur. Birime veri erişimi sağlamak için bu depolama uç noktasına tek bir IP adresi atanır. Birkaç birim oluşturursanız, tüm birimler bu depolama uç noktasına bağlı olarak temel alınan çıplak filoya dağıtılır. ANF, yapılandırılan depolama birimi veya/ve kapasitesi önceden tanımlanmış iç düzeye ulaştığında müşteri iş yüklerini otomatik olarak dağıtan bir mantığa sahiptir. Birimlere erişmek için yeni bir IP adresine sahip yeni bir depolama uç noktası otomatik olarak oluşturulduğundan bu tür durumları fark edebilirsiniz. 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 yineleme günlüğünü yazmak için "günlük birimi" (/hana/log) kullanılır. Bu nedenle, bu birimde bulunan açık dosyalar vardır ve bu birimin anlık görüntüsünü almak mantıklı değildir. Çevrimiçi yineleme günlük dosyaları, çevrimiçi yineleme günlük dosyası dolduktan veya yineleme günlüğü yedeklemesi yürütüldükten sonra 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 log-backup-volume değerini birleştirmek mantıklı olabilir. Böylece birden çok HANA örneği aynı birimi kullanır ve yedeklerini farklı dizinlere yazar. Böyle bir birleştirmeyi kullanarak, birimi biraz daha büyütmeniz gerektiğinden ile daha fazla aktarım hızı elde edebilirsiniz.
Aynı durum, tam HANA veritabanı yedeklemelerini yazmak için kullandığınız birim için de geçerlidir.
Yedekleme
Azure Sanal Makineler'da SAP HANA için yedekleme kılavuzu makalesinde açıklandığı gibi sap HANA veritabanlarını yedekleme ve akış yedekleme ve Azure Back hizmeti dışında, Azure NetApp Files depolama tabanlı anlık görüntü yedeklemeleri gerçekleştirme olanağı da sunar.
SAP HANA şu desteği destekler:
- SAP HANA 1.0 SPS7 ve üzeri yüklü tek kapsayıcılı sistem için Depolama tabanlı anlık görüntü yedekleme desteği
- SAP HANA 2.0 SPS1 ve üzeri yüklü tek kiracılı Çoklu Veritabanı Kapsayıcısı (MDC) HANA ortamları için Depolama tabanlı anlık görüntü yedekleme desteği
- SAP HANA 2.0 SPS4 ve üzeri sürümlere sahip birden çok kiracıya sahip Çoklu Veritabanı Kapsayıcısı (MDC) HANA ortamları için Depolama 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.
- HANA (iç) veritabanı anlık görüntüsü oluşturma - sizin veya araçların gerçekleştirmesi gereken etkinlik
- SAP HANA, depolamada tutarlı bir durum oluşturmak için veri dosyalarına veri yazar - HANA, HANA anlık görüntüsü oluşturmanın bir sonucu olarak bu adımı gerçekleştirir
- Depolamadaki /hana/data biriminde anlık görüntü oluşturun; sizin veya araçların gerçekleştirmesi gereken bir adımdır. /hana/log biriminde anlık görüntü gerçekleştirmeye gerek yoktur
- HANA (iç) veritabanı anlık görüntüsünü silme ve normal işlemi sürdürme - sizin veya araçların gerçekleştirmesi gereken bir adım
Uyarı
Son adımın eksik olması veya son adımın gerçekleştirilememesi SAP HANA'nın bellek talebini ciddi ölçüde etkiler ve SAP HANA'nın durmasına neden olabilir
BACKUP DATA FOR FULL SYSTEM CREATE SNAPSHOT COMMENT 'SNAPSHOT-2019-03-18:11:00';
az netappfiles snapshot create -g mygroup --account-name myaccname --pool-name mypoolname --volume-name myvolname --name mysnapname
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. Örneğin GitHub'da https://github.com/netapp/ntaphana kullanılabilen "ntaphana_azure.py" Python betiği Bu örnek koddur ve bakım veya destek olmadan "olduğu gibi" sağlanır.
Dikkat
Anlık görüntü, anlık görüntüsünü aldığın birimle aynı fiziksel depolama alanında bulunduğundan korumalı bir yedekleme değildir. Günde en az bir anlık görüntünün farklı bir konuma "korunması" zorunludur. Bu, aynı ortamda, uzak bir Azure bölgesinde veya Azure Blob depolamada yapılabilir.
Depolama anlık görüntüsü tabanlı uygulamayla tutarlı yedekleme için kullanılabilir çözümler:
- Microsoft Azure Uygulaması Lication Tutarlı Anlık Görüntü aracı, üçüncü taraf veritabanları için veri korumasını etkinleştiren bir komut satırı aracıdır. Depolama anlık görüntüsü almadan önce veritabanlarını uygulamayla tutarlı bir duruma getirmek için gereken tüm düzenlemeyi işler. Depolama anlık görüntüsü alındıktan sonra araç veritabanlarını işletimsel duruma döndürür. AzAcSnap, HANA Büyük Örneği ve Azure NetApp Files için anlık görüntü tabanlı yedeklemeleri destekler. daha fazla ayrıntı için Azure Uygulaması Lication Tutarlı Anlık Görüntü aracı nedir? makalesini okuyun
- Commvault yedekleme ürünleri kullanıcıları için bir diğer seçenek de Commvault IntelliSnap V.11.21 ve üzeridir. Commvault'un bu veya sonraki sürümleri Azure NetApp Files anlık görüntü desteği sunar. 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ü yedeklemelerini kaydetmek için uygun maliyetli ve hızlı bir yöntemdir. 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'dan Python betiğinin yüklü olduğu 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şitlenmiş olarak tutar. --delete-destination parametresinin kullanımı önemlidir. Bu parametre olmadan azcopy hedef sitedeki dosyaları silmeden hedef taraftaki alan kullanımı artar. Azure depolama hesabınızda bir Blok Blobu kapsayıcısı oluşturun. Ardından blob kapsayıcısı için SAS anahtarını oluşturun ve anlık görüntü klasörünü Azure Blob kapsayıcısına eşitleyin.
Örneğin, verileri korumak için günlük anlık görüntünün Azure blob kapsayıcısına eşitlenmesi gerekiyorsa. Yalnızca tek bir anlık görüntü tutulmalıdır, 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: