SAP iş yükü için Azure Sanal Makineler DBMS dağıtımıyla ilgili dikkat edilmesi gerekenler

  • Makale

Bu kılavuz, Microsoft Azure'da SAP yazılımı uygulama ve dağıtma belgelerinin bir parçasıdır. Bu kılavuzu okumadan önce Planlama ve uygulama kılavuzunu ve planlama kılavuzunun sizi işaret eden makalelerini okuyun. Bu belge, Hizmet olarak Azure altyapısı (IaaS) özelliklerini kullanarak Microsoft Azure sanal makinelerinde (VM) SAP ile ilgili DBMS sistemlerinin genel dağıtım yönlerini kapsar.

Bu makale, belirli platformlarda SAP yazılımının yükleme ve dağıtımları için birincil kaynakları temsil eden SAP yükleme belgelerini ve SAP Notlarını tamamlar.

Bu belgede, Azure VM'lerinde SAP ile ilgili DBMS sistemlerini çalıştırma konusunda dikkat edilmesi gerekenler sunulmuştur. Bu belgede belirli DBMS sistemlerine birkaç başvuru vardır. Bunun yerine, belirli DBMS sistemleri diğer veritabanı sistemine özgü belgelerde işlenir.

Kaynaklar

Azure'da SAP iş yüküyle ilgili başka makaleler de mevcuttur. Azure'da SAP iş yüküyle başlayın: Kullanmaya başlayın ve ilgi alanınızı seçin.

Aşağıdaki SAP Notları, bu belgede ele alınan alanla ilgili olarak Azure'da SAP ile ilgilidir.

Not numarası Başlık
1928533 Azure'da SAP uygulamaları: Desteklenen ürünler ve Azure VM türleri
2015553 Microsoft Azure'da SAP: Destek önkoşulları
1999351 SAP için gelişmiş Azure izleme sorunlarını giderme
2178632 Microsoft Azure'da SAP için önemli izleme ölçümleri
1409604 Windows'da sanallaştırma: Gelişmiş izleme
2191498 Azure ile Linux üzerinde SAP: Gelişmiş izleme
2039619 Oracle veritabanını kullanarak Microsoft Azure'da SAP uygulamaları: Desteklenen ürünler ve sürümler
2233094 DB6: Linux, UNIX ve Windows için IBM DB2 kullanan Azure'da SAP uygulamaları: Ek bilgiler
2243692 Microsoft Azure (IaaS) VM'sinde Linux: SAP lisans sorunları
2578899 SUSE Linux Enterprise Server 15: Yükleme Notu
1984787 SUSE LINUX Enterprise Server 12: Yükleme notları
2772999 Red Hat Enterprise Linux 8.x: Yükleme ve Yapılandırma
2002167 Red Hat Enterprise Linux 7.x: Yükleme ve yükseltme
2069760 Oracle Linux 7.x SAP yükleme ve yükseltme
1597355 Linux için alan değiştirme önerisi
2799900 Oracle Database 19c için Merkezi Teknik Not
2171857 Oracle Database 12c: Linux'ta dosya sistemi desteği
1114181 Oracle Database 11g: Linux'ta dosya sistemi desteği
2969063 Azure'da HCMT'de Mikro Kod Doğrulaması Başarısız Oldu
3246210 Azure - Bazı disk performans testleri sırasında HCMT başarısız oluyor

Linux için tüm SAP Notları hakkında bilgi için SAP topluluk wiki'sine bakın.

Microsoft Azure mimarisi ve Microsoft Azure sanal makinelerinin nasıl dağıtılıp çalıştırılacağı hakkında çalışan bir bilgiye ihtiyacınız vardır. Daha fazla bilgi için bkz . Azure belgeleri.

Genel olarak, Windows, Linux ve DBMS yükleme ve yapılandırması temelde şirket içinde yüklediğiniz tüm sanal makine veya çıplak makinelerle aynıdır. Azure IaaS kullandığınızda farklı mimari ve sistem yönetimi uygulama kararları vardır. Bu belgede, Azure IaaS kullanırken hazırlanacak belirli mimari ve sistem yönetimi farklılıkları açıklanmaktadır.

RDBMS dağıtımları için vm'nin Depolama yapısı

Bu bölümü takip etmek için, şu bölümlerde sunulan bilgileri okuyun ve anlayın:

Azure blok depolama için Azure yönetilen disklerinin kullanımı zorunludur. Azure yönetilen diskleri hakkında ayrıntılı bilgi için Azure VM'leri için yönetilen disklere giriş makalesini okuyun.

Temel bir yapılandırmada genellikle işletim sistemi, DBMS ve nihai SAP ikili dosyalarının veritabanı dosyalarından ayrı olduğu bir dağıtım yapısı öneririz. Aşağıdakiler için ayrı Azure diskleri kullanmanızı öneririz:

  • İşletim sistemi (temel VHD veya OS VHD)
  • Veritabanı yönetim sistemi yürütülebilir dosyaları
  • /usr/sap gibi SAP yürütülebilir dosyaları
  • DBMS veri dosyaları
  • DBMS günlük dosyalarını yineleme

Bu bileşenleri beş farklı birime ayıran bir yapılandırma, vm depolama kotası ve sınırları aşılmadığı sürece bir birimdeki aşırı kullanımın diğer birimlerin kullanımına müdahale etmemesi nedeniyle daha yüksek dayanıklılığa neden olabilir.

DBMS verileri ve işlem/yineleme günlük dosyaları Azure desteği blok depolama alanında veya Azure NetApp Files'da depolanır. Azure Dosyalar veya Azure Premium Dosyalar, DBSM verileri için depolama alanı olarak desteklenmez ve/veya SAP iş yüküyle günlük dosyalarını yineler. Bunlar ayrı disklerde depolanır ve özgün Azure işletim sistemi görüntüsü VM'sine mantıksal diskler olarak eklenir. Linux dağıtımları için farklı öneriler belgelenmiştir. Senaryonuza yönelik farklı depolama türlerinin özellikleri ve desteği için SAP iş yükü için Azure Depolama türleri makalesini okuyun. ÖZELLIKLE SAP HANA için, SAP HANA Azure sanal makine depolama yapılandırmaları makalesiyle başlayın.

Disk düzeninizi planlarken, şu öğeler arasındaki en iyi dengeyi bulun:

  • Veri dosyalarının sayısı.
  • Dosyaları içeren disklerin sayısı.
  • Tek bir diskin veya NFS paylaşımının IOPS kotaları.
  • Disk veya NFS paylaşımı başına veri aktarım hızı.
  • VM boyutu başına mümkün olan ek veri disklerinin sayısı.
  • Bir VM'nin sağlayabileceğiniz genel depolama veya ağ aktarım hızı.
  • Farklı Azure Depolama türlerinin sağlayabilecekleri gecikme süresi.
  • VM depolama IOPS ve aktarım hızı kotası.
  • NFS kullanıyorsanız VM ağ kotası - NFS paylaşımlarına yönelik trafik VM'nin ağ kotasına göre sayılıyor ve depolama kotasına DEĞİl .
  • VM SLA'ları.

Azure, veri diski veya NFS paylaşımı başına bir IOPS kotası uygular. Bu kotalar, farklı Azure blok depolama çözümlerinde veya paylaşımlarında barındırılan diskler için farklıdır. G/Ç gecikme süresi de bu farklı depolama türleri arasında farklıdır.

Farklı VM türlerinin her birinde ekleyebileceğiniz sınırlı sayıda veri diski vardır. Bir diğer kısıtlama da yalnızca belirli VM türlerinin (örneğin premium depolama) kullanılabilmesidir. Genellikle, CPU ve bellek gereksinimlerine göre belirli bir VM türü kullanmaya karar verirsiniz. Ayrıca genellikle disk sayısı veya premium depolama diskleri v1 türüyle ölçeklendirilen IOPS, gecikme süresi ve disk aktarım hızı gereksinimlerini de göz önünde bulundurmanız gerekir. IOPS sayısı ve her disk tarafından elde edilecek aktarım hızı, özellikle premium depolama v1 ile disk boyutunu dikte edebilir. Premium depolama v2 veya Ultra disk ile sağlanan IOPS ve aktarım hızını disk kapasitesinden bağımsız olarak seçebilirsiniz.

Dekont

DBMS dağıtımları için tüm veriler, işlem günlüğü veya yineleme dosyaları için Azure premium depolama (v1 ve v2), Ultra disk veya Azure NetApp Files tabanlı NFS paylaşımları önerilir. Üretim veya üretim dışı sistemleri dağıtmak isteyip istemediğiniz önemli değildir. Azure standart HDD veya SSD gecikme süresi, herhangi bir üretim sistemi türü için kabul edilemez.

Dekont

Azure'ın tek VM SLA'sını en üst düzeye çıkarmak için, eklenen tüm disklerin temel VHD'yi (Azure premium depolama) içeren Azure premium depolama (v1 veya v2) veya Azure Ultra disk türü olması gerekir.

Dekont

Azure veri merkezlerine bitişik üçüncü taraf veri merkezlerinde bulunan depolama donanımında SAP veritabanlarının veri ve günlük dosyaları gibi ana veritabanı dosyalarını barındırma desteklenmez. Azure VM'lerinde barındırılan yazılım gereçleri aracılığıyla sağlanan Depolama, bu kullanım örneği için de desteklenmez. SAP DBMS iş yükleri için, genel olarak SAP veritabanlarının veri ve işlem günlüğü dosyaları için yalnızca yerel Azure hizmeti olarak temsil edilen depolama desteklenir. Farklı DBMS, farklı Azure depolama türlerini desteklemektedir. Daha fazla ayrıntı için SAP iş yükü için Azure Depolama türleri makalesine bakın

Veritabanı dosyalarının, günlük ve yineleme dosyalarının yerleşimi ve kullandığınız Azure Depolama türü, IOPS, gecikme süresi ve aktarım hızı gereksinimleriyle tanımlanır. Özellikle Azure premium depolama v1 için yeterli IOPS elde etmek için birden çok disk kullanmak veya daha büyük bir premium depolama diski kullanmak zorunda kalabilirsiniz. Birden çok disk kullanıyorsanız, veri dosyalarını veya günlük ve yineleme dosyalarını içeren diskler arasında bir yazılım şeridi oluşturun. Bu gibi durumlarda, temel premium depolama disklerinin IOPS ve disk aktarım hızı SLA'ları veya standart depolama disklerinin maksimum ulaşılabilir IOPS değeri, sonuçta elde edilen şerit kümesi için birikebilir.

IOPS gereksiniminiz tek bir VHD'nin sağlayabileceklerini aşarsa, veritabanı dosyaları için gereken IOPS'yi bir dizi VHD arasında dengeleyin. IOPS yükünü diskler arasında dağıtmanın en kolay yolu, farklı diskler üzerinde bir yazılım şeridi oluşturmaktır. Ardından, yazılım şeridinden oyulmuş LUN'lara SAP DBMS'nin bir dizi veri dosyasını yerleştirin. Şeritteki disklerin sayısı IOPS taleplerine, disk aktarım hızı taleplerine ve birim taleplerine göre oluşturulur.

Windows storage striping Windows

Birden çok Azure VHD'sinde şerit kümeleri oluşturmak için Windows Depolama Spaces kullanmanızı öneririz. En az Windows Server 2012 R2 veya Windows Server 2016 kullanın.

Linux storage striping Linux

Linux üzerinde yazılım RAID'i oluşturmak için yalnızca MDADM ve Mantıksal Birim Yöneticisi (LVM) desteklenir. Daha fazla bilgi için bkz.

Azure premium depolama v2 ve Ultra disk için, diskin boyutundan bağımsız olarak IOPS ve disk aktarım hızı tanımlayabildiğiniz için şeritleme gerekli olmayabilir.

Dekont

Azure Depolama, VHD'lerin üç görüntülerini tuttuğundan, şerit oluştururken yedeklilik yapılandırmak mantıklı değildir. Yalnızca G/Ç'lerin farklı VHD'ler üzerinden dağıtılması için şeritleme yapılandırmanız gerekir.

Yönetilen veya yönetilmeyen diskler

Azure depolama hesabı bir yönetim yapısıdır ve ayrıca sınırlamaların konusudur. Özellikler ve sınırlamalar hakkında bilgi için bkz. Azure Depolama ölçeklenebilirlik ve performans hedefleri. Standart depolama için, depolama hesabı başına IOPS'de bir sınır olduğunu unutmayın. Azure Depolama ölçeklenebilirlik ve performans hedefleri makalesindeki Toplam İstek Oranı'nı içeren satıra bakın. Azure aboneliği başına depolama hesabı sayısı için de bir başlangıç sınırı vardır. 2017'de Azure, depolama hesabı yönetimiyle ilgilenmenizi sağlayan Azure Yönetilen Diskler kavramlarını kullanıma sunulmuştur. Azure yönetilen diskleri kullanmak, Azure'da SAP iş yükü için dağıtılacak varsayılan değerdir.

Önemli

Azure Yönetilen Diskler avantajları göz önünde bulundurulduğunda, DBMS dağıtımlarınız ve SAP dağıtımlarınız için genel olarak Azure Yönetilen Diskler kullanmanız zorunludur.

Henüz yönetilen diskleri kullanmayan SAP iş yükünüz varsa, yönetilmeyen disklerden yönetilen disklere dönüştürmek için bkz:

VM'ler ve veri diskleri için Önbelleğe Alma

VM'lere disk bağladığınızda, VM ile Azure depolamada bulunan diskler arasındaki G/Ç trafiğinin önbelleğe alınıp alınmayacağını seçebilirsiniz.

Aşağıdaki önerilerde, standart DBMS için bu G/Ç özellikleri varsayılır:

  • Çoğunlukla bir veritabanının veri dosyalarına karşı okuma iş yükü olur. Bu okumalar DBMS sistemi için performans açısından kritik öneme sahiptir.
  • Veri dosyalarına karşı yazma, denetim noktalarına veya sabit bir akışa göre seri aralıklarla gerçekleşir. Bir gün içinde ortalaması alınan yazma sayısı, okumalardan daha azdır. Veri dosyalarından okuma işlemlerinin aksine, bu yazma işlemleri zaman uyumsuz olur ve hiçbir kullanıcı işlemini tutmaz.
  • İşlem günlüğünden veya yineleme dosyalarından neredeyse hiç okuma yok. İşlem günlüğü yedeklemeleri gerçekleştirdiğinizde özel durumlar büyük G/Ç'lerdir.
  • İşlem veya yineleme günlük dosyalarına karşı ana yük yazma işlemidir. İş yükünün yapısına bağlı olarak, G/Ç'niz 4 KB kadar küçük olabilir veya diğer durumlarda 1 MB veya daha fazla G/Ç boyutuna sahip olabilirsiniz.
  • Tüm yazma işlemleri diskte güvenilir bir şekilde kalıcı olmalıdır.

Azure premium depolama v1 için aşağıdaki önbelleğe alma seçenekleri vardır:

  • Hiçbiri
  • Okundu
  • Okuma/yazma
  • Yok + Yazma Hızlandırıcısı, yalnızca Azure M Serisi VM'lere yöneliktir
  • Okuma + Yazma Hızlandırıcısı, yalnızca Azure M Serisi VM'lere yöneliktir

Premium depolama v1 için SAP veritabanının veri dosyaları için Okuma önbelleği'ni kullanmanızı ve günlük dosyalarının diskleri için Önbelleğe alma yok'u seçmenizi öneririz.

M Serisi dağıtımları için Azure Yazma Hızlandırıcısı'nı yalnızca günlük dosyalarınızın diskleri için kullanmanızı öneririz. Azure Yazma Hızlandırıcısı'nın ayrıntıları, kısıtlamaları ve dağıtımı için bkz . Yazma Hızlandırıcısını Etkinleştirme.

Premium depolama v2, Ultra disk ve Azure NetApp Files için önbelleğe alma seçeneği sunulmaz.

Azure kalıcı olmayan diskler

Azure VM'leri, vm dağıtıldıktan sonra kalıcı olmayan diskler sunar. Bir VM yeniden başlatılırsa, bu sürücülerdeki tüm içerik silinebilir. Veri dosyalarının ve veritabanlarının günlük ve yineleme dosyalarının, söz konusu kalıcı olmayan sürücülerde hiçbir koşulda bulunmaması gerektiği bir durum olarak kabul edilir. Bazı veritabanlarında, bu kalıcı olmayan sürücülerin tempdb ve temp tablespaces için uygun olabileceği özel durumlar olabilir.

Daha fazla bilgi için bkz . Azure'daki Windows VM'lerindeki geçici sürücüyü anlama.

Windows nonpersisted disk Windows

Azure VM'sindeki D sürücüsü, Azure işlem düğümündeki bazı yerel diskler tarafından yedeklenen, kalıcı olmayan bir sürücüdür. Kayıtsız olmadığından, VM yeniden başlatıldığında D sürücüsündeki içerikte yapılan tüm değişiklikler kaybolur. Değişiklikler depolanmış dosyaları, oluşturulan dizinleri ve yüklü uygulamaları içerir.

Linuxnonpersisted disk Linux

Linux Azure VM'leri, Azure işlem düğümündeki yerel diskler tarafından desteklenen ve kalıcı olmayan bir sürücü olan /mnt/resource konumuna otomatik olarak bir sürücü bağlar. Kalıcı olmadığından, /mnt/resource içindeki içerikte yapılan tüm değişiklikler VM yeniden başlatıldığında kaybolur. Değişiklikler depolanmış dosyaları, oluşturulan dizinleri ve yüklü uygulamaları içerir.

Microsoft Azure Depolama dayanıklılığı

Microsoft Azure Depolama işletim sistemi ve bağlı diskler veya bloblar ile temel VHD'yi en az üç ayrı depolama düğümünde depolar. Bu tür depolama, yerel olarak yedekli depolama (LRS) olarak adlandırılır. LRS, Azure'daki tüm depolama türleri için varsayılan değerdir.

Başka yedeklilik yöntemleri de vardır. Daha fazla bilgi için bkz. Azure Depolama çoğaltma.

Dekont

Azure premium depolama v1 ve v2, Ultra disk ve Azure NetApp Files, veritabanı ve günlük ve yineleme dosyalarını depolayan DBMS VM'leri ve diskleri için önerilen depolama türüdür. Premium depolama v1 dışında, bu depolama türleri için kullanılabilen tek yedeklilik yöntemi LRS'dir. Sonuç olarak, veritabanı verilerini başka bir Azure bölgesine veya kullanılabilirlik alanına çoğaltmayı etkinleştirmek için veritabanı yöntemlerini yapılandırmanız gerekir. Veritabanı yöntemleri SQL Server Always On, Oracle Data Guard ve HANA Sistem Çoğaltma'yı içerir.

VM düğümü dayanıklılığı

Azure, VM'ler için birkaç farklı SLA sunar. Daha fazla bilgi için Sanal Makineler için SLA'nın en son sürümüne bakın. DBMS katmanı bir SAP sisteminde kullanılabilirlik açısından kritik öneme sahip olduğundan, farklı dağıtım türlerini ve bakım olaylarını anlamanız gerekir. Bu kavramlar hakkında daha fazla bilgi için bkz . Azure'da sanal makinelerin kullanılabilirliğini yönetme.

SAP iş yüküne sahip üretim DBMS senaryoları için en düşük öneri:

  • Aynı Azure bölgesinde seçilen dağıtım türünü kullanarak iki VM dağıtın.
  • Bu iki VM'yi aynı Azure sanal ağında çalıştırın ve NIC'lerin aynı alt ağlara bağlı olması.
  • İkinci VM ile çalışırken beklemede tutmak için veritabanı yöntemlerini kullanın. Yöntemler SQL Server Always On, Oracle Data Guard veya HANA Sistem Çoğaltması olabilir.

Ayrıca başka bir Azure bölgesine üçüncü bir VM dağıtabilir ve aynı veritabanı yöntemlerini kullanarak başka bir Azure bölgesinde zaman uyumsuz çoğaltma sağlayabilirsiniz.

Azure ağıyla ilgili dikkat edilmesi gerekenler

Büyük ölçekli SAP dağıtımlarında Azure Sanal Veri Merkezi şemasını kullanın. Bunu sanal ağ yapılandırmanız, kuruluşunuzun farklı bölümlerine izinler ve rol atamaları için kullanın.

Bu en iyi yöntemler, binlerce müşteri dağıtımının sonucu olarak elde edilir:

  • SAP uygulamasının dağıtılacağı sanal ağların İnternet erişimi yoktur.
  • Veritabanı VM'leri, SAP uygulama katmanından farklı bir alt ağda ayrılmış olarak uygulama katmanıyla aynı sanal ağda çalışır.
  • Sanal ağ içindeki VM'ler özel IP adresini statik olarak ayırmaya sahiptir. Daha fazla bilgi için bkz . Azure'da IP adresi türleri ve ayırma yöntemleri.
  • DBMS VM'lerine ve vm'lerinden yönlendirme kısıtlamaları, yerel DBMS VM'lerinde yüklü güvenlik duvarlarıyla ayarlanmamıştır . Bunun yerine, trafik yönlendirmesi ağ güvenlik grupları (NSG) ile tanımlanır.
  • DBMS VM'sine gelen trafiği ayırmak ve yalıtmak için VM'ye farklı NIC'ler atayın. Her NIC farklı bir IP adresi alır ve her NIC farklı bir sanal ağ alt ağına atanır. Her alt ağın farklı NSG kuralları vardır. Ağ trafiğinin yalıtımı veya ayrılması yönlendirmeye yönelik bir ölçüdür. Ağ aktarım hızı kotalarını ayarlamak için kullanılmaz.

Dekont

Azure aracılığıyla statik IP adresleri atamak, bunları tek tek sanal NIC'lere atamak anlamına gelir. Konuk işletim sistemi içindeki statik IP adreslerini bir sanal NIC'ye atamayın. Azure Backup gibi bazı Azure hizmetleri, konuk işletim sistemindeki birincil sanal NIC'nin statik IP adreslerine değil DHCP'ye ayarlandığı gerçeğinden yararlanır. Daha fazla bilgi için bkz . Azure sanal makine yedekleme sorunlarını giderme. Vm'ye birden çok statik IP adresi atamak için vm'ye birden çok sanal NIC atayın.

Uyarı

SAP uygulaması ile SAP NetWeaver, Hybris veya S/4HANA tabanlı SAP sisteminin DBMS katmanı arasındaki iletişim yolunda ağ sanal gereçlerinin yapılandırılması desteklenmez. Bu kısıtlama, işlevsellik ve performans nedenlerinden dolayıdır. SAP uygulama katmanı ile DBMS katmanı arasındaki iletişim yolu doğrudan bir yol olmalıdır. Bu ASG ve NSG kuralları doğrudan iletişim yoluna izin veriyorsa kısıtlama uygulama güvenlik grubu (ASG) ve NSG kurallarını içermez. Bu, DBMS verilerini barındıran ve günlük dosyalarını yineleyen NFS paylaşımlarına yönelik trafiği de içerir.

Ağ sanal gereçlerinin desteklenmediği diğer senaryolar şunlardır:

  • Linux Pacemaker küme düğümlerini temsil eden Azure VM'leri ile SBD cihazları arasındaki iletişim yolları, SAP Uygulamaları için SUSE Linux Enterprise Server'daki Azure VM'lerinde SAP NetWeaver için yüksek kullanılabilirlik bölümünde açıklandığı gibi.
  • Azure VM'leri ile Windows Server Genişleme Dosya Sunucusu (SOFS) arasındaki iletişim yolları, Azure'da bir dosya paylaşımı kullanarak Windows yük devretme kümesinde SAP ASCS/SCS örneğini kümeleme bölümünde açıklandığı gibi ayarlanır.

İletişim yollarındaki ağ sanal gereçleri, iki iletişim ortağı arasındaki ağ gecikme süresini kolayca ikiye katlayabilir. Ayrıca SAP uygulama katmanı ile DBMS katmanı arasındaki kritik yollarda aktarım hızını kısıtlayabilirler. Bazı müşteri senaryolarında ağ sanal gereçleri Pacemaker Linux kümelerinin başarısız olmasına neden olabilir. Bunlar, Linux Pacemaker küme düğümleri arasındaki iletişimlerin bir ağ sanal gereci aracılığıyla SBD cihazlarıyla iletişim kurması durumlarıdır.

Ö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ı yerine azure sanal ağı içindeki alt ağları kullanarak ayırmanızı öneririz.

Öneriye uymamaya ve bunun yerine iki katmanı farklı sanal ağlara ayırmaya karar verirseniz, iki sanal ağın eşlenmiş olması gerekir.

eşlenmiş iki Azure sanal ağı arasındaki ağ trafiğinin aktarım maliyetlerine tabi olduğunu unutmayın. SAP uygulama katmanı ile DBMS katmanı arasında çok sayıda terabayttan oluşan büyük veri hacmi değiştirilir. SAP uygulama katmanı ve DBMS katmanı eşlenmiş iki Azure sanal ağı arasında ayrılmışsa önemli maliyetler biriktirebilirsiniz.

Trafiği yeniden yönlendirmek için Azure Load Balancer'ı kullanma

SQL Server Always On veya HANA Sistem Çoğaltması gibi işlevlerde kullanılan özel sanal IP adreslerinin kullanılması için Azure yük dengeleyicinin yapılandırılması gerekir. Yük dengeleyici, etkin DBMS düğümünü belirlemek ve trafiği yalnızca bu etkin veritabanı düğümüne yönlendirmek için yoklama bağlantı noktalarını kullanır.

Veritabanı düğümünün yük devretmesi varsa SAP uygulamasının yeniden yapılandırılmasına gerek yoktur. Bunun yerine, en yaygın SAP uygulama mimarileri özel sanal IP adresine yeniden bağlanır. Bu arada yük dengeleyici, trafiği özel sanal IP adresine göre ikinci düğüme yönlendirerek düğüm yük devretmesine tepki gösterir.

Azure iki farklı yük dengeleyici SKU'su sunar: temel SKU ve standart bir SKU. Kurulum ve işlevsellik avantajlarına bağlı olarak, Azure yük dengeleyicinin Standart SKU'sunu kullanmanız gerekir. Yük dengeleyicinin Standart sürümünün en büyük avantajlarından biri, veri trafiğinin yük dengeleyicinin kendisi üzerinden yönlendirilmeyen olmasıdır.

İç yük dengeleyiciyi nasıl yapılandırabileceğinize ilişkin bir örnek, Öğretici: Azure'da SQL Server kullanılabilirlik grubunu el ile yapılandırma Sanal Makineler makalesinde bulunabilir

Dekont

Genel IP adreslerinin erişimiyle ilgili temel ve standart SKU'nun davranışında farklılıklar vardır. Standart SKU'nun genel IP adreslerine erişme kısıtlamalarına geçici bir çözüm bulmanın yolu, SAP yüksek kullanılabilirlik senaryolarında Azure Standart Load Balancer kullanarak Sanal Makineler için genel uç nokta bağlantısı belgesinde açıklanmıştır

Konak izleme dağıtımı

SAP uygulamalarının Azure sanal makinelerinde üretim kullanımı için SAP, Azure sanal makinelerini çalıştıran fiziksel konaklardan konak izleme verilerini alabilmeyi gerektirir. SAPOSCOL ve SAP Konak Aracısı'nda bu özelliği etkinleştiren belirli bir SAP Konak Aracısı düzeltme eki düzeyi gereklidir. Tam düzeltme eki düzeyi SAP Not 1409604 belgelenmiştir.

SAPOSCOL ve SAP Konak Aracısı'na konak verileri teslim eden bileşenlerin dağıtımı ve bu bileşenlerin yaşam döngüsü yönetimi hakkında daha fazla bilgi için SAP çözümleri için Azure VM uzantısını uygulama makalesiyle başlayın.

Sonraki adımlar

Belirli bir DBMS hakkında daha fazla bilgi için bkz: