Aracılığıyla paylaş

Azure'da SAP HANA altyapı yapılandırmaları ve işlemleri

  • Makale

Bu belge, Azure altyapısını yapılandırmaya ve Azure yerel sanal makinelerinde (VM) dağıtılan SAP HANA sistemlerini çalıştırmaya yönelik yönergeler sağlar. Belge ayrıca M128s VM SKU'su için SAP HANA ölçeği genişletme yapılandırma bilgilerini de içerir. Bu belge, aşağıdaki içeriği içeren standart SAP belgelerinin yerini alacak şekilde tasarlanmamıştır:

Önkoşullar

Bu kılavuzu kullanmak için aşağıdaki Azure bileşenleri hakkında temel bilgilere sahip olmanız gerekir:

SAP NetWeaver ve Azure'da diğer SAP bileşenleri hakkında daha fazla bilgi edinmek için Azure belgelerinin Azure'da SAP bölümüne bakın.

Temel kurulum konuları

Aşağıdaki bölümlerde, Azure VM'lerinde SAP HANA sistemlerini dağıtmaya yönelik temel kurulum konuları açıklanmaktadır.

Azure sanal makinelerine bağlanma

Azure sanal makineleri planlama kılavuzunda belirtildiği gibi, Azure VM'lerine bağlanmak için iki temel yöntem vardır:

  • Bir Atlama VM'sinde veya SAP HANA çalıştıran VM'de İnternet ve genel uç noktalar üzerinden bağlanın.
  • VPN veya Azure ExpressRoute üzerinden bağlanın.

Üretim senaryoları için VPN veya ExpressRoute üzerinden siteden siteye bağlantı gereklidir. Bu tür bir bağlantı, SAP yazılımının kullanıldığı üretim senaryolarına beslenen üretim dışı senaryolar için de gereklidir. Aşağıdaki görüntüde siteler arası bağlantı örneği gösterilmektedir:

Siteler arası bağlantı

Azure VM türlerini seçme

SAP, üretim senaryoları için kullanabileceğiniz Azure VM türlerini listeler. Üretim dışı senaryolar için daha çeşitli yerel Azure VM türleri kullanılabilir.

Not

Üretim dışı senaryolar için SAP notu #1928533 listelenen VM türlerini kullanın. Üretim senaryoları için Azure VM'lerinin kullanımı için SAP tarafından yayımlanan Sertifikalı IaaS Platformları listesinde SAP HANA sertifikalı VM'leri denetleyin.

Aşağıdakileri kullanarak Azure'da VM'leri dağıtma:

  • Azure portal.
  • Azure PowerShell cmdlet'leri.
  • Azure CLI.

Ayrıca, SAP Cloud platformu aracılığıyla Azure VM hizmetlerine eksiksiz bir yüklü SAP HANA platformu dağıtabilirsiniz. Yükleme işlemi, Azure'da SAP S/4HANA veya BW/4HANA dağıtma bölümünde açıklanmıştır.

Önemli

M208xx_v2 VM'leri kullanmak için Linux görüntünüzü seçerken dikkatli olmanız gerekir. Daha fazla bilgi için bkz . Bellek için iyileştirilmiş sanal makine boyutları.

SAP HANA için depolama yapılandırması

Azure'da SAP HANA ile kullanılacak depolama yapılandırmaları ve depolama türleri için SAP HANA Azure sanal makine depolama yapılandırmaları belgesini okuyun

Azure sanal ağlarını ayarlama

VPN veya ExpressRoute aracılığıyla Azure'a siteden siteye bağlantınız olduğunda, Sanal Ağ Geçidi üzerinden VPN veya ExpressRoute bağlantı hattına bağlı en az bir Azure sanal ağınız olmalıdır. Basit dağıtımlarda Sanal Ağ Geçidi, SAP HANA örneklerini barındıran Azure sanal ağının (VNet) bir alt ağına da dağıtılabilir. SAP HANA'yı yüklemek için Azure sanal ağı içinde iki alt ağ daha oluşturursunuz. Bir alt ağ, SAP HANA örneklerini çalıştırmak için VM'leri barındırıyor. Diğer alt ağ, SAP HANA Studio, diğer yönetim yazılımları veya uygulama yazılımınızı barındırmak için Jumpbox veya Yönetim VM'lerini çalıştırır.

Önemli

İşlevsellik yetersiz olsa da performans nedeniyle daha önemli olan, SAP uygulaması ile SAP NetWeaver, Hybris veya S/4HANA tabanlı SAP sisteminin DBMS katmanı arasındaki iletişim yolunda Azure Ağ Sanal Gereçleri'nin yapılandırılması desteklenmez. SAP uygulama katmanı ile DBMS katmanı arasındaki iletişimin doğrudan olması gerekir. Bu ASG ve NSG kuralları doğrudan iletişime izin verdikçe kısıtlama Azure ASG ve NSG kurallarını içermez. NVA'ların desteklenmediği diğer senaryolar, SAP uygulamaları için SUSE Linux Enterprise Server üzerinde Azure VM'lerinde SAP NetWeaver için yüksek kullanılabilirlik bölümünde açıklandığı gibi Linux Pacemaker küme düğümlerini temsil eden Azure VM'leri ile SBD cihazları arasındaki iletişim yollarındadır. Azure'da bir dosya paylaşımı kullanarak Windows yük devretme kümesinde SAP ASCS/SCS örneğini kümele bölümünde açıklandığı gibi ayarlanan Azure VM'leri ile Windows Server SOFS arasındaki iletişim yollarında da kullanabilirsiniz. İletişim yollarındaki NVA'lar, iki iletişim ortağı arasındaki ağ gecikme süresini kolayca ikiye katlayabilir, SAP uygulama katmanı ile DBMS katmanı arasındaki kritik yollarda aktarım hızını kısıtlayabilir. Müşterilerle birlikte gözlemlenen bazı senaryolarda NVA'lar, Linux Pacemaker küme düğümleri arasındaki iletişimin bir NVA aracılığıyla SBD cihazlarıyla iletişim kurması gereken durumlarda Pacemaker Linux kümelerinin başarısız olmasına neden olabilir.

Önemli

DESTEKLENMEYEN bir diğer tasarım da SAP uygulama katmanının ve DBMS katmanının birbiriyle eşlenmemiş farklı Azure sanal ağlarına ayrılmasıdır. Sap uygulama katmanını ve DBMS katmanını farklı Azure sanal ağları kullanmak yerine bir Azure sanal ağı içindeki alt ağları kullanarak ayırmanız önerilir. Öneriyi izlememeye karar verirseniz ve bunun yerine iki katmanı farklı sanal ağa ayırırsanız, iki sanal ağın eşlenmiş olması gerekir. İki eşlenmiş Azure sanal ağı arasındaki ağ trafiğinin aktarım maliyetlerine tabi olduğunu unutmayın. SAP uygulama katmanı ile DBMS katmanı arasında birçok Terabaytlık büyük veri hacminin değişimiyle, SAP uygulama katmanı ve DBMS katmanı eşlenmiş iki Azure sanal ağı arasında ayrıştırılırsa önemli maliyetler birikebilir.

Jumpbox veya yönetim VM'lerini ayrı bir alt ağa dağıttıysanız, HANA VM için her vNIC farklı alt ağa atanmış birden çok sanal ağ arabirimi kartı (vNIC) tanımlayabilirsiniz. Birden çok vNIC'ye sahip olma özelliği sayesinde, gerekirse ağ trafiği ayrımı ayarlayabilirsiniz. Örneğin, istemci trafiği birincil vNIC üzerinden yönlendirilebilir ve yönetici trafiği ikinci bir vNIC üzerinden yönlendirilir.
Ayrıca her iki sanal NIC için de dağıtılan statik özel IP adresleri atarsınız.

Not

Tek tek vNIC'lere Azure ortalamaları aracılığıyla statik IP adresleri atamanız gerekir. Konuk işletim sistemi içindeki statik IP adreslerini bir vNIC'ye atamamalısınız. Azure Backup Hizmeti gibi bazı Azure hizmetleri, en azından birincil vNIC'nin statik IP adreslerine değil DHCP'ye ayarlandığı gerçeğinden yararlanır. Ayrıca Bkz. Azure sanal makine yedekleme sorunlarını giderme. Bir VM'ye birden çok statik IP adresi atamanız gerekiyorsa, vm'ye birden çok vNIC atamanız gerekir.

Ancak, kalıcı olan dağıtımlar için Azure'da bir sanal veri merkezi ağ mimarisi oluşturmanız gerekir. Bu mimari, şirket içine bağlanan Azure VNet Ağ Geçidi'nin ayrı bir Azure VNet'e ayrılmasını önerir. Bu ayrı sanal ağ, şirket içi veya İnternet'e ayrılan tüm trafiği barındırmalıdır. Bu yaklaşım, azure'daki sanal veri merkezine bu ayrı merkez sanal aya giren trafiği denetlemek ve günlüğe kaydetmek için yazılım dağıtmanıza olanak tanır. Bu nedenle, Azure dağıtımınıza gelen ve giden trafikle ilgili tüm yazılım ve yapılandırmaları barındıran bir sanal ağınız vardır.

Azure Sanal Veri Merkezi: Ağ Perspektifi ve Azure Sanal Veri Merkezi ve Kurumsal Denetim Düzlemi makaleleri, sanal veri merkezi yaklaşımı ve ilgili Azure sanal ağ tasarımı hakkında daha fazla bilgi sağlar.

Not

Azure sanal ağ eşlemesi kullanılarak merkez sanal ağı ile uç sanal ağı arasında akan trafik ek maliyetlere tabidir. Bu maliyetlere bağlı olarak, sanal ağ eşlemesini atlamak için katı bir merkez-uç ağ tasarımı çalıştırma ile 'uçlara' bağladığınız birden çok Azure ExpressRoute Ağ Geçidi çalıştırma arasında tavizler vermeniz gerekebilir. Ancak Azure ExpressRoute Ağ Geçitleri ek maliyetler de sağlar . Ağ trafiği günlüğü, denetim ve izleme için kullandığınız üçüncü taraf yazılımlara yönelik ek maliyetlerle de karşılaşabilirsiniz. Bir tarafta sanal ağ eşlemesi aracılığıyla veri alışverişi maliyetlerine ve ek Azure ExpressRoute Ağ Geçitleri ve ek yazılım lisansları tarafından oluşturulan maliyetlere bağlı olarak, alt ağları sanal ağlar yerine yalıtım birimi olarak kullanarak bir sanal ağ içinde mikro segmentlere ayırmaya karar vekleyebilirsiniz.

IP adresleri atamaya yönelik farklı yöntemlere genel bakış için bkz . Azure'da IP adresi türleri ve ayırma yöntemleri.

SAP HANA çalıştıran VM'ler için, atanmış statik IP adresleriyle çalışmanız gerekir. Bunun nedeni, HANA için bazı yapılandırma özniteliklerinin IP adreslerine başvurmasıdır.

Azure Ağ Güvenlik Grupları (NSG), SAP HANA örneğine veya sıçrama kutusuna yönlendirilen trafiği yönlendirmek için kullanılır. NSG'ler ve sonunda Uygulama Güvenlik Grupları SAP HANA alt ağı ve Yönetim alt ağı ile ilişkilendirilir.

Sap HANA'yı siteden siteye bağlantı olmadan Azure'da dağıtmak için, SAP HANA örneğini genel İnternet'ten korumak ve ileri ara sunucu arkasında gizlemek isteyebilirsiniz. Bu temel senaryoda dağıtım, ana bilgisayar adlarını çözümlemek için Azure yerleşik DNS hizmetlerine dayanır. Genel kullanıma yönelik IP adreslerinin kullanıldığı daha karmaşık bir dağıtımda, Azure yerleşik DNS hizmetleri özellikle önemlidir. İnternet'ten Azure'daki Azure sanal ağ mimarinize yönlendirmeyi denetlemek, izlemek için Azure NSG'lerini ve Azure NVA'larını kullanın. Aşağıdaki görüntüde, sap HANA'yı merkez-uç sanal ağ mimarisinde siteden siteye bağlantı olmadan dağıtmaya yönelik kaba bir şema gösterilmektedir:

Siteden siteye bağlantısı olmayan SAP HANA için kaba dağıtım şeması

Merkez-uç sanal ağ mimarisi olmadan İnternet'ten erişimi denetlemek ve izlemek için Azure NVA'larının nasıl kullanılacağına ilişkin başka bir açıklama, Yüksek oranda kullanılabilir ağ sanal gereçlerini dağıtma makalesinde bulunabilir.

Azure VM'lerinde saat kaynağı seçenekleri

SAP HANA, en iyi performansı elde etmek için güvenilir ve doğru zamanlama bilgileri gerektirir. Geleneksel olarak Azure hiper yöneticisinde çalışan Azure VM'leri varsayılan saat kaynağı olarak yalnızca Hyper-V TSC sayfasını kullanır. Donanım, konak işletim sistemi ve Linux konuk işletim sistemi çekirdeklerindeki teknoloji ilerlemeleri, bazı Azure VM SKU'larında saat kaynağı seçeneği olarak "Sabit TSC" sağlamayı mümkün hale getirdi.

Hyper-V TSC sayfası (hyperv_clocksource_tsc_page), tüm Azure VM'lerinde saat kaynağı olarak desteklenir. Temel alınan donanım, hiper yönetici ve konuk işletim sistemi linux çekirdeği Sabit TSC'yi destekliyorsa, tsc Azure VM'lerindeki konuk işletim sisteminde kullanılabilir ve desteklenen saat kaynağı olarak sunulur.

SAP HANA ölçeği genişletme için Azure altyapısını yapılandırma

OLAP ölçeğini genişletme veya S/4HANA ölçeği genişletme için sertifikalı Azure VM türlerini bulmak için SAP HANA donanım dizinine bakın. 'Kümeleme' sütunundaki onay işareti ölçeği genişletme desteğini gösterir. Uygulama türü OLAP ölçeğini genişletme veya S/4HANA ölçeği genişletmenin desteklenip desteklenmediğini gösterir. Ölçeği genişletme sertifikasına sahip düğümlerle ilgili ayrıntılar için SAP HANA donanım dizininde listelenen belirli bir VM SKU'sunun girişini gözden geçirin.

Azure VM'lerinde ölçeği genişletme yapılandırmalarını dağıtmak için en düşük işletim sistemi sürümleri, SAP HANA donanım dizininde listelenen belirli VM SKU'sunda yer alan girdilerin ayrıntılarını denetleyin. N düğümlü OLAP ölçeği genişletme yapılandırmasında, bir düğüm ana düğüm olarak çalışır. Sertifika sınırına kadar olan diğer düğümler çalışan düğümü görevi görür. Diğer hazır bekleyen düğümler, sertifikalı düğüm sayısına dahil değildir

Not

Bekleme düğümüne sahip SAP HANA'nın Azure VM ölçeği genişletme dağıtımları yalnızca Azure NetApp Files depolama kullanılarak mümkündür. BAŞKA SAP HANA sertifikalı Azure depolama alanı, SAP HANA bekleme düğümlerinin yapılandırılmasına izin verir

/hana/shared için Azure NetApp Files veya Azure Dosyalar kullanımını öneririz.

Azure NetApp Files'da dağıtılan, ölçeği genişletme yapılandırmasındaki /hana/shared tek bir düğüm için tipik bir temel tasarım şöyle görünür:

Ölçeği genişletme yapılandırmasında tek bir düğüm için tipik bir temel tasarımı gösteren diyagram.

SAP HANA ölçeği genişletme için bir VM düğümünün temel yapılandırması şöyle görünür:

  • /hana/shared için Azure NetApp Files veya Azure Dosyalar aracılığıyla sağlanan yerel NFS hizmetini kullanırsınız.
  • Diğer tüm disk birimleri farklı düğümler arasında paylaşılmamaktadır ve NFS'yi temel almıyor. Bu belgenin devamında paylaşılmayan /hana/data ve /hana/log ile ölçeği genişleten HANA yüklemeleri için yükleme yapılandırmaları ve adımları sağlanmıştır. Kullanılabilecek HANA sertifikalı depolama için SAP HANA Azure sanal makine depolama yapılandırmaları makalesine bakın.

Birimleri veya diskleri boyutlandırdığınızda, çalışan düğümlerinin sayısına bağlı olarak gereken boyut için SAP HANA TDI Depolama Gereksinimleri belgesini denetlemeniz gerekir. Belge, birimin gerekli kapasitesini almak için uygulamanız gereken bir formülü yayınlar

Ölçeği genişletilen SAP HANA VM'sinin tek düğümlü yapılandırmasının grafiklerinde görüntülenen diğer tasarım ölçütleri sanal ağdır veya alt ağ yapılandırması daha iyidir. SAP, istemciye/uygulamaya yönelik trafiğin HANA düğümleri arasındaki iletişimlerden ayrılmasını kesinlikle önerir. Grafiklerde gösterildiği gibi, bu hedefe VM'ye iki farklı vNIC eklenerek ulaşılır. Her iki vNIC de farklı alt ağlarda yer alır ve iki farklı IP adresine sahiptir. Ardından NSG'leri veya kullanıcı tanımlı yolları kullanarak yönlendirme kurallarıyla trafik akışını denetleyebilirsiniz.

Özellikle Azure'da, belirli vNIC'lerde hizmet kalitesini ve kotaları zorunlu kılmanın hiçbir yöntemi ve yöntemi yoktur. Sonuç olarak, istemciye/uygulamaya yönelik ve düğüm içi iletişimin ayrılması, bir trafik akışını diğer trafik akışına göre önceliklendirme fırsatına neden olmaz. Bunun yerine ayrım, ölçek genişletme yapılandırmalarının düğüm içi iletişimlerini korumada bir güvenlik ölçüsü olarak kalır.

Not

SAP, bu belgede açıklandığı gibi ağ trafiğini istemci/uygulama tarafı ve düğüm içi trafiğe ayırmanızı önerir. Bu nedenle, son grafiklerde gösterildiği gibi bir mimarinin yerine koyması önerilir. Ayrıca öneriden sapan gereksinimler için güvenlik ve uyumluluk ekibinize başvurun

Ağ açısından gerekli en düşük ağ mimarisi şöyle görünür:

Tek bir düğümün ölçeğini genişletme temelleri

SAP HANA ölçeğini genişletme n Azure'ı yükleme

Ölçeği genişletme SAP yapılandırmasını yüklerken aşağıdakilerin kaba adımlarını gerçekleştirmeniz gerekir:

  • Yeni dağıtım veya mevcut azure sanal ağ altyapısını uyarlama
  • ANF tabanlı Azure Yönetilen Premium Depolama, Ultra disk birimleri ve/veya NFS birimleri kullanarak yeni VM'leri dağıtma
    • Ağ yönlendirmesini, örneğin VM'ler arasındaki düğüm içi iletişimin bir NVA üzerinden yönlendirilemediğinden emin olmak için uyarlar.
  • SAP HANA ana düğümünü yükleyin.
  • SAP HANA ana düğümünün yapılandırma parametrelerini uyarlama
  • SAP HANA çalışan düğümlerini yüklemeye devam edin

Genişleme yapılandırmasında SAP HANA yüklemesi

Azure VM altyapınız dağıtıldıktan ve diğer tüm hazırlıklar tamamlandıktan sonra şu adımlarda SAP HANA ölçeği genişletme yapılandırmalarını yüklemeniz gerekir:

  • SAP HANA ana düğümünü SAP belgelerine göre yükleme
  • azure /hana/logPremium Depolama veya Ve'nin paylaşılmayan /hana/data diskleriyle Ultra disk depolama kullanırken parametresini basepath_shared = no dosyaya global.ini ekleyin. Bu parametre, SAP HANA'nın düğümler arasında paylaşılan /hana/data ve /hana/log birimler olmadan ölçeği genişletmede çalışmasını sağlar. Ayrıntılar SAP Not #2080991 belgelenmiştir. /hana/data ve /hana/log için ANF'yi temel alan NFS birimleri kullanıyorsanız, bu değişikliği yapmanız gerekmez
  • global.ini parametresindeki nihai değişiklik sonrasında SAP HANA örneğini yeniden başlatın
  • Daha fazla çalışan düğümü ekleyin. Daha fazla bilgi için bkz . Komut Satırı Arabirimini Kullanarak Konak Ekleme. Yükleme sırasında veya daha sonra, örneğin yerel hdblcm kullanarak SAP HANA düğümler arası iletişim için iç ağı belirtin. Daha ayrıntılı belgeler için bkz . SAP Notu #2183363.

Hazır bekleyen düğümle SAP HANA genişleme sistemi ayarlamak için SUSE Linux dağıtım yönergelerine veya Red Hat dağıtım yönergelerine bakın.

Azure sanal makineleri için SAP HANA Dinamik Katmanlama 2.0

Azure M serisi VM'lerdeki SAP HANA sertifikalarına ek olarak, SAP HANA Dinamik Katmanlama 2.0 da Microsoft Azure'da desteklenir. Daha fazla bilgi için bkz . DT 2.0 bağlantıları belgeleri. Ürünü yükleme veya çalıştırmada fark yoktur. Örneğin, SAP HANA Kokpit'i bir Azure VM'sine yükleyebilirsiniz. Ancak, Azure'da resmi destek için aşağıdaki bölümde açıklandığı gibi bazı zorunlu gereksinimler vardır. Makale boyunca tam adı Dinamik Katmanlama 2.0 yerine "DT 2.0" kısaltması kullanılacaktır.

SAP HANA Dinamik Katmanlama 2.0, SAP BW veya S4HANA tarafından desteklenmez. Şu anda ana kullanım örnekleri yerel HANA uygulamalarıdır.

Genel bakış

Aşağıdaki resimde Microsoft Azure'da DT 2.0 desteğiyle ilgili genel bir bakış sağlanır. Resmi sertifikasyona uymak için uyulması gereken bir dizi zorunlu gereksinim vardır:

  • DT 2.0, ayrılmış bir Azure VM'sinde yüklü olmalıdır. SAP HANA'nın çalıştığı vm'de çalışmayabilir
  • SAP HANA ve DT 2.0 VM'leri aynı Azure sanal ağı içinde dağıtılmalıdır
  • SAP HANA ve DT 2.0 VM'leri Azure hızlandırılmış ağ etkinleştirilmiş olarak dağıtılmalıdır
  • DT 2.0 VM'leri için depolama türü Azure Premium Depolama olmalıdır
  • DT 2.0 VM'sine birden çok Azure diski eklenmelidir
  • Azure diskleri arasında şeritleme kullanarak bir yazılım baskını /şeritli birim (lvm veya mdadm aracılığıyla) oluşturmak gerekir

Diğer ayrıntılar aşağıdaki bölümlerde açıklanacak.

SAP HANA DT 2.0 Mimarisine Genel Bakış

SAP HANA DT 2.0 için ayrılmış Azure VM

Azure IaaS'de DT 2.0 yalnızca ayrılmış bir VM'de desteklenir. HANA örneğinin çalıştığı Azure VM'de DT 2.0 çalıştırmasına izin verilmez. Başlangıçta SAP HANA DT 2.0'ı çalıştırmak için iki VM türü kullanılabilir:

  • M64-32ms
  • E32sv3

VM türü açıklaması hakkında daha fazla bilgi için bkz. Azure VM boyutları - Bellek

Maliyet tasarrufu sağlamak için "sıcak" verilerin boşaltılmasıyla ilgili temel DT 2.0 fikri dikkate alındığında ilgili VM boyutlarının kullanılması mantıklıdır. Ancak olası kombinasyonlarla ilgili katı bir kural yoktur. Bu, belirli bir müşteri iş yüküne bağlıdır.

Önerilen yapılandırmalar:

SAP HANA VM türü DT 2.0 VM türü
M128ms M64-32ms
M128s M64-32ms
M64ms E32sv3
M64s E32sv3

Desteklenen DT 2.0 VM'lere (M64-32ms ve E32sv3) sahip SAP HANA sertifikalı M serisi VM'lerin tüm birleşimleri mümkündür.

Azure ağı ve SAP HANA DT 2.0

DT 2.0'ı ayrılmış bir VM'ye yüklemek için DT 2.0 VM ile SAP HANA VM arasında en az 10 Gb ağ aktarım hızı gerekir. Bu nedenle tüm VM'leri aynı Azure sanal ağına yerleştirmek ve Azure hızlandırılmış ağı etkinleştirmek zorunlu olur.

Azure hızlandırılmış ağ hakkında ek bilgilere bakın: Azure CLI kullanarak Hızlandırılmış Ağ ile Azure VM oluşturma

SAP HANA DT 2.0 için VM Depolama

DT 2.0 en iyi uygulama kılavuzuna göre disk GÇ aktarım hızı fiziksel çekirdek başına en az 50 MB/sn olmalıdır.

DT 2.0 için desteklenen iki Azure VM türünün belirtimlerine göre, VM için maksimum disk GÇ aktarım hızı sınırı şöyle görünür:

  • E32sv3: 768 MB/sn (kazınmamış) yani fiziksel çekirdek başına 48 MB/sn oran
  • M64-32ms: 1000 MB/sn (kazınmamış) yani fiziksel çekirdek başına 62,5 MB/sn oran

DT 2.0 VM'ye birden çok Azure diski eklemek ve VM başına maksimum disk aktarım hızı sınırına ulaşmak için işletim sistemi düzeyinde bir yazılım baskını (şeritleme) oluşturmak gerekir. Tek bir Azure diski, bu konuda maksimum VM sınırına ulaşmak için aktarım hızı sağlayamaz. DT 2.0'ı çalıştırmak için Azure Premium depolama zorunludur.

  • Kullanılabilir Azure disk türleri hakkındaki ayrıntılar Azure IaaS VM'leri için disk türü seçin - yönetilen diskler sayfasında bulunabilir
  • mdadm aracılığıyla yazılım baskını oluşturma hakkındaki ayrıntılar Linux VM'de yazılım RAID'ini yapılandırma sayfasında bulunabilir
  • LVM'yi maksimum aktarım hızı için şeritli birim oluşturacak şekilde yapılandırma hakkındaki ayrıntılara Linux çalıştıran bir sanal makinede LVM'yi yapılandırma sayfasından ulaşabilirsiniz

Boyut gereksinimlerine bağlı olarak, vm'nin maksimum aktarım hızına ulaşmak için farklı seçenekler vardır. Üst VM aktarım hızı sınırına ulaşmak için her DT 2.0 VM türü için olası veri birimi disk yapılandırmaları aşağıdadır. E32sv3 VM,daha küçük iş yükleri için giriş düzeyi olarak değerlendirilmelidir. Yeterince hızlı olmadığı ortaya çıkması durumunda VM'yi M64-32ms olarak yeniden boyutlandırmak gerekebilir. M64-32ms VM'de çok fazla bellek olduğundan, GÇ yükü özellikle yoğun okuma kullanan iş yükleri için sınıra ulaşamayabilir. Bu nedenle, müşteriye özgü iş yüküne bağlı olarak şerit kümesindeki daha az disk yeterli olabilir. Ancak güvenli tarafta olmak için en yüksek aktarım hızını garanti etmek için aşağıdaki disk yapılandırmaları seçildi:

VM SKU Disk Yapılandırması 1 Disk Yapılandırması 2 Disk Yapılandırması 3 Disk Yapılandırması 4 Disk Yapılandırması 5
M64-32ms 4 x P50 -> 16 TB 4 x P40 -> 8 TB 5 x P30 -> 5 TB 7 x P20 -> 3,5 TB 8 x P15 -> 2 TB
E32sv3 3 x P50 -> 12 TB 3 x P40 -> 6 TB 4 x P30 -> 4 TB 5 x P20 -> 2,5 TB 6 x P15 -> 1,5 TB

Özellikle iş yükünün okuma açısından yoğun olması durumunda, veritabanı yazılımının veri hacimleri için önerilen Şekilde Azure ana bilgisayar önbelleğini "salt okunur" olarak açmak GÇ performansını artırabilir. İşlem günlüğü için Azure ana bilgisayar disk önbelleği "yok" olmalıdır.

Günlük biriminin boyutuyla ilgili olarak önerilen bir başlangıç noktası, veri boyutunun %15'inin buluşsal bir örneğidir. Günlük birimi oluşturma işlemi, maliyet ve aktarım hızı gereksinimlerine bağlı olarak farklı Azure disk türleri kullanılarak gerçekleştirilebilir. Günlük birimi için yüksek G/Ç aktarım hızı gerekir.

VM türü M64-32ms kullanılırken Yazma Hızlandırıcısı'nın etkinleştirilmesi zorunlu olur. Azure Yazma Hızlandırıcısı işlem günlüğü için en uygun disk yazma gecikme süresini sağlar (yalnızca M serisi için kullanılabilir). VM türü başına en fazla disk sayısı gibi dikkate alınması gereken bazı öğeler vardır. Yazma Hızlandırıcısı hakkındaki ayrıntılara Azure Yazma Hızlandırıcısı sayfasından ulaşabilirsiniz

Günlük birimini boyutlandırma hakkında birkaç örnek aşağıda verilmiştir:

veri birimi boyutu ve disk türü günlük birimi ve disk türü yapılandırması 1 günlük birimi ve disk türü yapılandırması 2
4 x P50 -> 16 TB 5 x P20 -> 2,5 TB 3 x P30 -> 3 TB
6 x P15 -> 1,5 TB 4 x P6 -> 256 GB 1 x P15 -> 256 GB

SAP HANA ölçeği genişletmede olduğu gibi/hana/shared dizininin SAP HANA VM ile DT 2.0 VM arasında paylaşılması gerekir. Yüksek oranda kullanılabilir bir NFS sunucusu işlevi üstlenen ayrılmış VM'ler kullanılarak SAP HANA ölçeğini genişletme ile aynı mimari önerilir. Paylaşılan bir yedekleme birimi sağlamak için aynı tasarım kullanılabilir. Ancak, HA'nın gerekli olup olmadığı veya yalnızca yedekleme sunucusu olarak görev yapmak için yeterli depolama kapasitesine sahip ayrılmış bir VM kullanmak yeterli olup olmadığı müşteriye aittir.

Azure VM'lerinde SAP HANA dağıtma işlemleri

Aşağıdaki bölümlerde, Azure VM'lerinde SAP HANA sistemlerini dağıtmayla ilgili bazı işlemler açıklanmaktadır.

Azure VM'lerinde yedekleme ve geri yükleme işlemleri

Aşağıdaki belgelerde SAP HANA dağıtımınızın nasıl yedekleneceği ve geri yükleneceği açıklanmaktadır:

SAP HANA içeren VM'leri başlatma ve yeniden başlatma

Azure genel bulutunun öne çıkan özelliklerinden biri, yalnızca işlem dakikalarınız için ücretlendirilmiş olmanızdır. Örneğin, SAP HANA çalıştıran bir VM'yi kapattığınızda, yalnızca bu süre boyunca depolama maliyetleri için faturalandırılırsınız. İlk dağıtımınızda VM'leriniz için statik IP adresleri belirttiğinizde başka bir özellik kullanılabilir. SAP HANA içeren bir VM'yi yeniden başlattığınızda, VM önceki IP adresleriyle yeniden başlatılır.

SAP uzaktan desteği için SAProuter kullanma

Şirket içi konumlarınızla Azure arasında siteden siteye bağlantınız varsa ve SAP bileşenlerini çalıştırıyorsanız, büyük olasılıkla zaten SAProuter kullanıyorsunuz demektir. Bu durumda, uzaktan destek için aşağıdaki öğeleri tamamlayın:

  • SAProuter yapılandırmasında SAP HANA'yı barındıran VM'nin özel ve statik IP adresini koruyun.
  • 3299 numaralı TCP/IP bağlantı noktası üzerinden trafiğe izin vermek için HANA VM'sini barındıran alt ağın NSG'sini yapılandırın.

Azure'a İnternet üzerinden bağlanıyorsanız ve SAP HANA ile VM için bir SAP yönlendiriciniz yoksa, bileşeni yüklemeniz gerekir. SAProuter'ı Yönetim alt ağından ayrı bir VM'ye yükleyin. Aşağıdaki görüntüde, siteden siteye bağlantı olmadan ve SAProuter ile SAP HANA'yı dağıtmak için kaba bir şema gösterilmektedir:

Siteden siteye bağlantı ve SAProuter olmadan SAP HANA için kaba dağıtım şeması

SAProuter'ı Jumpbox VM'nize değil ayrı bir VM'ye yüklediğinizden emin olun. Ayrı VM'nin statik BIR IP adresi olmalıdır. SAProuter'ınızı SAP tarafından barındırılan SAProuter'a bağlamak için BIR IP adresi için SAP ile iletişime geçin. (SAP tarafından barındırılan SAProuter, VM'nize yüklediğiniz SAProuter örneğinin karşılığıdır.) SAProuter örneğinizi yapılandırmak için SAP'nin IP adresini kullanın. Yapılandırma ayarlarında, gereken tek bağlantı noktası 3299 numaralı TCP bağlantı noktasıdır.

SAProuter aracılığıyla uzaktan destek bağlantıları kurma ve sürdürme hakkında daha fazla bilgi için SAP belgelerine bakın.

Azure yerel VM'lerinde SAP HANA ile yüksek kullanılabilirlik

SUSE Linux Enterprise Server veya Red Hat çalıştırıyorsanız, eskrim cihazlarıyla bir Pacemaker kümesi oluşturabilirsiniz. Cihazları, HANA Sistem Çoğaltması ve otomatik yük devretme ile zaman uyumlu çoğaltma kullanan bir SAP HANA yapılandırması ayarlamak için kullanabilirsiniz. 'Sonraki adımlar' bölümünde listelenen daha fazla bilgi için.

Sonraki Adımlar

Listelenen makaleler hakkında bilgi edinin