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

Bu kılavuz, sap yazılımını uygulama ve uygulama ile ilgili belgelerin bir parçası Microsoft Azure. Bu kılavuzu okumadan önce Planlama ve uygulama kılavuzunu ve planlama kılavuzunun sizi yönlendiren makalelerini okuyun. Bu belge, Azure hizmet olarak altyapı (IaaS) özelliklerini kullanarak Microsoft Azure sanal makinelerde (VM) SAP ile ilgili DBMS sistemlerinin genel dağıtım yönlerini kapsar.

Bu makale, sap yazılımının ilgili platformlarda yüklenmesi ve dağıtımı için birincil kaynakları temsil eden SAP yükleme belgelerini ve SAP Notes'ı tamamlar.

Bu belgede, Azure VM'lerde SAP ile ilgili DBMS sistemlerini çalıştırmayla ilgili dikkat edilmesi gerekenler tanıtıldı. Bu bölümde belirli DBMS sistemlerine yönelik birkaç başvuru vardır. Bunun yerine, belirli DBMS sistemleri bu belgeden sonra bu yazıda ele almaktadır.

Tanımlar

Belge boyunca şu terimler kullanılır:

  • IaaS: Hizmet olarak altyapı.

  • PaaS: Hizmet olarak platform.

  • SaaS: Hizmet olarak yazılım.

  • SAP bileşeni: ERP Central Component (ECC), Business Warehouse (BW), Solution Manager veya Enterprise Portal (EP) gibi tek bir SAP uygulaması. SAP bileşenleri, geleneksel ABAP veya Java teknolojilerini veya İş Nesneleri gibi NetWeaver tabanlı olmayan bir uygulamayı temel alıyor olabilir.

  • SAP ortamı: Geliştirme, kalite güvencesi, eğitim, olağanüstü durum kurtarma veya üretim gibi bir iş işlevini gerçekleştirmek için mantıksal olarak gruplu bir veya daha fazla SAP bileşeni.

  • SAP alanı: Bu terim, müşterinin IT ortamının tüm SAP varlıklarını ifade eder. SAP ortamı tüm üretim ortamlarını ve üretim dışı ortamları içerir.

  • SAP sistemi: BIR DBMS katmanının ve örneğin SAP ERP geliştirme sisteminin, SAP Business Warehouse test sisteminin veya SAP CRM üretim sisteminin bir uygulama katmanının birleşimidir. Azure dağıtımlarında bu iki katmanın şirket içi ile Azure arasında bölünmesi desteklenmiyor. Sonuç olarak SAP sistemi şirket içinde veya Azure'da dağıtılır. Sap ortamının farklı sistemlerini Azure'da veya şirket içinde dağıtabilirsiniz. Örneğin, Azure'da SAP CRM geliştirme ve test sistemlerini dağıtabilirsiniz ancak SAP CRM üretim sistemini şirket içinde dağıtabilirsiniz.

  • Şirket içi ve dışı: Şirket içi veri merkezleriyle Azure arasında siteden siteye, çoklu site veya Azure ExpressRoute bağlantısı olan bir Azure aboneliğine VM'ler dağıtılacağı bir senaryoyu açıklar. Yaygın Azure belgelerinde bu tür dağıtımlar şirket içi ve şirket içi ve şirket içi senaryolar olarak da açıklanmıştır.

    Bağlantının nedeni şirket içi etki alanlarını, etki alanlarını ve şirket içi Active Directory DNS'yi Azure'a genişletmektir. Şirket içi ortamı, aboneliğin Azure varlıklarına genişletildi. Bu uzantıyla, VM'ler şirket içi etki alanının parçası olabilir. Şirket içi etki alanının etki alanı kullanıcıları sunuculara erişe ve DBMS hizmetleri gibi bu VM'lerde hizmetleri çalıştırarak. Şirket içinde dağıtılan VM'ler ile Azure'da dağıtılan VM'ler arasında iletişim ve ad çözümlemesi mümkündür. Bu senaryo, Azure'da SAP varlıklarını dağıtmak için kullanılan en yaygın senaryodur. Daha fazla bilgi için bkz. VPN ağ geçidi için planlama ve tasarlama.

Not

SAP sistemlerinin şirket içi dağıtımları, SAP sistemlerini çalıştıran Azure sanal makinelerinin şirket içi bir etki alanının üyesi olduğu ve üretim SAP sistemleri için destekleneleridir. Azure'a parça dağıtmak veya SAP ortamını tamamlamak için şirket içi ve şirket içi yapılandırmalar desteklemektedir. Azure'da tam SAP ortamını çalıştırmanız bile bu VM'lerin bir şirket içi etki alanının ve Active Directory/LDAP'nin parçası olması gerekir.

Belgelerin önceki sürümlerinde karma-IT senaryolarına değinildi. Karma teriminin kök nedeni, şirket içi ile Azure arasında şirket içi ve şirket içi bağlantı olmasıdır. Bu durumda karma, Azure'daki VM'ler de sanal şirket içi Active Directory.

Bazı Microsoft belgelerinde özellikle DBMS yüksek kullanılabilirlik yapılandırmaları için şirket içi ve şirket içi senaryolar biraz farklı açıklanmıştır. SAP ile ilgili belgelerde, şirket içi ve azure arasında dağıtılan bir SAP ortamı ve siteden siteye veya özel ExpressRoute bağlantısına kadar olan şirket içi senaryolar arası senaryo ortaya konur.

Kaynaklar

Azure'da SAP iş yüküyle ilgili başka makaleler de mevcuttur. Azure'da SAP iş yüküyle Kullanmaya başlayın ve ardından istediğiniz alanı seçin.

Aşağıdaki SAP Notları, bu Azure üzerinde SAP kapsamındaki alanla ilgili bilgilerle ilgilidir.

Not numarası Başlık
1928533 Azure'da SAP uygulamaları: Desteklenen ürünler ve Azure VM türleri
2015553 sap on Microsoft Azure: 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 sanallaştırma: Gelişmiş izleme
2191498 Azure ile Linux üzerinde SAP: Gelişmiş izleme
2039619 Oracle veritabanını Microsoft Azure sap uygulamaları: Desteklenen ürünler ve sürümler
2233094 DB6: Linux, UNIX ve Windows IBM DB2 kullanan Azure'da SAP uygulamaları: Ek bilgiler
2243692 Linux on Microsoft Azure (IaaS) VM: SAP lisans sorunları
1984787 SUSE LINUX Enterprise Server 12: Yükleme notları
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 değiştirme alanı önerisi
2171857 Oracle Database 12c: Linux'ta dosya sistemi desteği
1114181 Oracle Database 11g: Linux'ta dosya sistemi desteği

Linux için SAP Notlarına ilişkin tüm bilgiler için bkz. SAP community wiki.

Sanal makinelerin nasıl dağıtılacağı ve Microsoft Azure ve Microsoft Azure hakkında bilgi sahibi olmak gerekir. Daha fazla bilgi için bkz. Azure belgeleri.

Genel olarak, Windows, Linux ve DBMS yüklemesi ve yapılandırması temelde şirket içinde yüklemiş olduğu tüm sanal makinelerle veya çıplak makinelerle aynıdır. Azure IaaS'i kullanırken farklı mimari ve sistem yönetimi uygulama kararları vardır. Bu belgede, Azure IaaS'i kullanırken hazırlanacak belirli mimari ve sistem yönetimi farkları açıklanmıştır.

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

Bu bölümü takip etmek için şu bölümde sunulan bilgileri okuyun ve an edin:

Bu bölümü okumadan önce farklı depolama VM-Series ve standart ve premium depolama arasındaki farkları anlamanız ve bu konuda bilgilisiniz.

Azure blok depolama için Azure yönetilen disklerin kullanılması kesinlikle önerilir. Azure yönetilen diskleri hakkında ayrıntılı bilgi için Azure VM'leri için yönetilen disklere giriş makalesine bakın.

Temel yapılandırmada genellikle işletim sisteminin, DBMS'nin ve son SAP ikili dosyalarının veritabanı dosyalarından ayrı olduğu bir dağıtım yapısı önerilir. Önceki önerileri değiştirerek aşağıdakiler için ayrı Azure diskleri kullanılması önerilir:

  • İşletim sistemi (temel VHD veya İşletim Sistemi VHD'si)
  • Veritabanı yönetim sistemi yürütülebilir dosyaları
  • /usr/sap gibi SAP yürütülebilir dosyaları

BU bileşenleri üç farklı Azure diskine ayıran bir yapılandırma, DBMS veya SAP yürütülebilir dosyaları tarafından aşırı günlük veya döküm yazmaları işletim sistemi disk kotalarına müdahale etmeyiş olduğundan daha yüksek bir resilete neden olabilir.

DBMS verileri ve işlem/yenidendo günlük dosyaları, Azure tarafından desteklenen blok depolama veya Azure NetApp Files. Bunlar ayrı disklerde depolanır ve özgün Azure işletim sistemi görüntüsü VM'sinde mantıksal diskler olarak takılıdır. Linux dağıtımları için, özellikle de dağıtımlar için farklı SAP HANA. Özellikler ve senaryo için Depolama türleri desteği için Azure sap iş yükü türleri makalesine bakın.

Disk düzeninizi planlarken, bu öğ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 ek veri diski sayısı.
  • Bir VM'nin sağlay etki alanına veya ağ aktarım hızına genel olarak sahip olabilir.
  • Gecikme süresi farklı Azure Depolama sağ yardımcı olabilir.
  • VM SLA'ları.

Azure, veri diski veya NFS paylaşımı başına IOPS kotası zorlar. Bu kotalar, farklı Azure blok depolama çözümlerde veya paylaşımlarda barındırılan diskler için farklıdır. Bu farklı depolama türleri arasında da işletim sistemi gecikme süresi farklıdır.

Farklı VM türlerinin her biri, ekleyebilirsiniz sınırlı sayıda veri diski içerir. Bir diğer kısıtlama da yalnızca belirli VM türlerinin (örneğin, premium depolama) kullanamalarıdır. Genellikle CPU ve bellek gereksinimlerine göre belirli bir VM türünü kullanmaya karar verirsiniz. Ayrıca genellikle disk sayısı veya premium depolama disklerinin türüyle ölçeklendiren IOPS, gecikme süresi ve disk aktarım hızı gereksinimlerini de göz önünde bulundurabilirsiniz. IOPS sayısı ve her disk tarafından elde edilen aktarım hızı, özellikle premium depolamada disk boyutunu dikte edilebilir.

Not

DBMS dağıtımları için tüm veriler, işlem günlüğü veya Azure NetApp Files için Azure premium depolama, Ultra disk veya Azure NetApp Files tabanlı NFS paylaşımları (yalnızca SAP HANA için) önerilir. Üretim sistemlerini mi yoksa üretim dışı sistemleri mi dağıtmak istediğiniz önemli değildir.

Not

Azure'ın tek VM SLA'larındanyararlanmak için, eklenen tüm disklerin temel VHD(Azure premium depolama) içeren Azure premium depolama veya Azure Ultra disk türü olması gerekir.

Not

SAP veritabanlarının veri ve günlük dosyaları gibi ana veritabanı dosyalarını Azure veri merkezlerinin yanında, birlikte bulunan üçüncü taraf veri merkezlerinde bulunan depolama donanımlarında barındırma desteklenmiyor. Depolama Azure VM'lerinde barındırılan yazılım gereçleri aracılığıyla sağlanan yazılımlar, bu kullanım örneğinde de desteklanmaz. SAP DBMS iş yükleri için, genel olarak SAP veritabanlarının verileri ve işlem günlüğü dosyaları için yalnızca yerel Azure hizmeti olarak temsil edilen depolama alanı de geçerlidir. Farklı DBMS, farklı Azure depolama türlerini destekleyebildi. Diğer ayrıntılar için SAP iş yükü için Azure Depolama türleri makalesine bakın

Veritabanı dosyalarının, günlük ve yenidendo dosyalarının yerleşimi ve azure Depolama türü, IOPS, gecikme süresi ve aktarım hızı gereksinimlerine göre tanımlanır. Azure premium depolamanın yeterli IOPS elde etmek için birden çok disk kullanmaya veya daha büyük bir premium depolama diski kullanmaya zorlanmasına neden olabilir. Birden çok disk kullanıyorsanız, veri dosyalarını veya günlük ve yenidendo dosyalarını içeren diskler arasında bir yazılım şeridi oluşturabilirsiniz. Böyle durumlarda, temel alınan 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ğlarını aşıyorsa, veritabanı dosyaları için gereken IOPS sayısını bir dizi VHD arasında dengeler. 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, SAP DBMS'nin bir dizi veri dosyalarını yazılım şeridinin dışında bulunan LUN'lara yer. Şeritte yer alan disklerin sayısı IOPS talepleri, disk aktarım hızı talepleri ve birim talepleri tarafından yönlendirildi.


Windows alanı şeritle Windows

Birden çok Azure VHD'Windows Depolama Alanları şerit kümeleri oluşturmak için kümeler kullanmanızı öneririz. R2 veya Windows Server 2012 en az Windows Server 2016.

Linux depolama şeritle Linux

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


Azure Ultra disk için, disk boyutundan bağımsız olarak IOPS ve disk aktarım hızı tanımladığınız için şerit oluşturma gerekli değildir.

Not

Azure Depolama VHD'lerin üç görüntülerini tutar, şeritlerken yedeklilik yapılandırmak mantıklı değil. Yalnızca, I/O'ların farklı VHD'ler üzerinde dağıtılması için şeritley yapılandırmaya ihtiyacınız vardır.

Yönetilen veya yönetilmeyen diskler

Azure depolama hesabı bir yönetim yapısıdır ve sınırlamaların da konusudur. Sınırlamalar standart depolama hesapları ve premium depolama hesapları arasında farklılık gösterir. Ö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 sınırı olduğunu unutmayın. Azure'ın ölçeklenebilirlik ve performans hedefleri makalesinde Toplam İstek Depolama içeren satıra bakın. Ayrıca Azure aboneliği başına depolama hesabı sayısına bir başlangıç sınırı da vardır. Bu depolama hesaplarının sınırlarına varmamak için farklı depolama hesaplarında daha büyük SAP ortamı için VHD'leri dengeler. Binden fazla VHD'ye sahip birkaç yüz sanal makineden söz ediyorken bu sıkıcı bir iştir.

DBMS dağıtımları için SAP iş yüküyle birlikte standart depolama kullanılması önerilmez. Bu nedenle, standart depolamaya yapılan başvurular ve öneriler bu kısa makaleyle sınırlıdır

VHD'leri farklı Azure depolama hesaplarına planlama ve dağıtmanın yönetimsel çalışmalarından kaçınmak için Microsoft, 2017'de Azure Yönetilen Diskler'yi tanıtmıştı. Yönetilen diskler standart depolama ve premium depolama için kullanılabilir. Yönetilen disklerin yönetilmeyen disklere kıyasla başlıca avantajları:

  • Yönetilen diskler için Azure, farklı VHD'leri dağıtım zamanında otomatik olarak farklı depolama hesaplarına dağıtır. Bu şekilde veri hacmi, I/O aktarım hızı ve IOPS için depolama hesabı sınırlarına isabet etmez.
  • Yönetilen diskleri kullanan Azure Depolama, Azure kullanılabilirlik kümelerinin kavramlarını yerine alır. VM bir Azure kullanılabilirlik kümesine bağlı ise, bir VM'nin temel VHD ve bağlı diski farklı hata ve güncelleştirme etki alanlarına dağıtılır.

Önemli

Azure Yönetilen Diskler avantajlarına göre, GENEL OLARAK DBMS dağıtımları Yönetilen Diskler SAP dağıtımları için Azure Yönetilen Diskler'i kullanmanızı kesinlikle öneririz.

Yönetilemeyen disklerden yönetilen disklere dönüştürmek için bkz:

Önbelleğe Alma ve veri diskleri için yapılandırma

Vm'lere diskleri bağlarken, VM ile Azure depolamada bulunan diskler arasındaki G/Ç trafiğinin önbelleğe alınıp alınıp alın olmadığını seçebilirsiniz.

Aşağıdaki öneriler, standart DBMS için bu I/O özelliklerini varsayıyor:

  • Ç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 bağlı olarak seri aralıklarda gerçekleşir. Bir gün boyunca ortalama olarak, okumalardan daha az yazma vardır. Veri dosyalarından yapılan okumaların aksine, bu yazma işlemleri zaman uyumsuz olur ve herhangi bir kullanıcı işlemi tutmaz.
  • İşlem günlüğünden veya yenidendo dosyalarından neredeyse hiç okuma işlemi yok. İşlem günlüğü yedeklemeleri gerçekleştirecek olan büyük G/Ç'ler özel durumlardır.
  • İşlem veya yenidendo günlük dosyalarına karşı ana yük yazma işlemidir. İş yükünün yapısına bağlı olarak, 4 KB'a kadar küçük veya diğer durumlarda 1 MB veya daha büyük bir I/O boyutuna sahip olabilirsiniz.
  • Tüm yazmalar diskte güvenilir bir şekilde kalıcı olmalıdır.

Standart depolama için olası önbellek türleri:

  • Hiçbiri
  • Okuma
  • Okuma/Yazma

Tutarlı ve belirlenimci performans elde etmek için DBMS ile ilgili veri dosyaları, günlük ve yenidendo dosyaları ve tablo alanı içeren tüm diskler için standart depolamada önbelleğe almayı NONE olarak ayarlayın. Temel VHD'nin önbelleğe alma özelliği varsayılan değerle birlikte kalır.

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

  • Hiçbiri
  • Okuma
  • Okuma/yazma
  • Hiçbiri + Yazma Hızlandırıcısı, yalnızca Azure M Serisi VM'ler için
  • Okuma + Yazma Hızlandırıcısı, bu yalnızca Azure M Serisi VM'ler için

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

M Serisi dağıtımlar için, DBMS dağıtımınız için Azure Yazma Hızlandırıcısı'i kullanmanızı öneririz. Azure Yazma Hızlandırıcısı'nin ayrıntıları, kısıtlamaları ve dağıtımı için bkz. Yazma Hızlandırıcısı.

Ultra disk ve Azure NetApp Files önbelleğe alma seçeneği yoktur.

Azure'da var olmayan diskler

Azure VM'leri, BIR VM dağıtıldıktan sonra kullanılabilir olmayan diskler sunar. VM'nin yeniden başlatılması durumunda bu sürücülerde yer alan tüm içerik silinir. Bu durum, veritabanlarının veri dosyaları ve günlük ve yeniden oluşturma dosyalarının, bu aralıksız sürücülerde hiçbir koşulda yer almamalarını gerektirir. Bazı veritabanları için bu aralıksız sürücülerin tempdb ve temp tablespaces için uygun olabileceği özel durumlar olabilir. Bu performanssız sürücüler, bu VM ailesi ile aktarım hızı sınırlı olduğundan, A Serisi VM'ler için bu sürücüleri kullanmaktan kaçının.

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


Windows olmayan disk Windows

Azure VM'sinde D sürücüsü, Azure işlem düğümünde bazı yerel diskler tarafından delen, performansı olmayan bir sürücü olur. Bu aralıksız olduğundan, D sürücüsünde içerikte yapılan tüm değişiklikler VM yeniden başlatıldığında kaybolur. Değişiklikler arasında depolanan dosyalar, oluşturulan dizinler ve yüklü uygulamalar yer aldı.

Linuxnonpersisted disk Linux

Linux Azure VM'leri/ /mnt/resource kaynağına otomatik olarak bir sürücü bağlar. Bu sürücü, Azure işlem düğümünde yerel diskler tarafından desteklenir. Bu, /mnt/resource içeriğinde yapılan değişiklikler, VM yeniden başlatıldığında kaybedilir. Değişiklikler arasında depolanan dosyalar, oluşturulan dizinler ve yüklü uygulamalar yer aldı.


Microsoft Azure Depolama ve daha fazla

Microsoft Azure Depolama işletim sistemi ve bağlı diskler veya blob'lar ile en az üç ayrı depolama düğümünde temel VHD'nin depolanması gerekir. Bu depolama türü yerel olarak yedekli depolama (LRS) olarak adlandırılan bir depolama alanıdır. LRS, Azure'daki tüm depolama türleri için varsayılandır.

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

Not

Azure premium depolama, Ultra disk ve Azure NetApp Files (özel olarak SAP HANA için), veritabanı ve günlük ve yenidendo dosyalarını depolarken DBMS VM'leri ve diskler için önerilen depolama timdir. 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 bölgesine çoğaltmayı etkinleştirmek için veritabanı yöntemlerini yapılandırmanız gerekir. Veritabanı yöntemleri Always On SQL Server Oracle Data Guard ve HANA Sistem Çoğaltması'dır.

Not

DBMS dağıtımlarında, standart depolama için coğrafi olarak yedekli depolama (GRS) kullanılması önerilmez. GRS, performansı ciddi şekilde etkiler ve bir VM'ye bağlı olan farklı VHD'ler arasında yazma sırasına saygı gösterir. Farklı VHD'ler arasında yazma sırasına saygının gerektirilamama olasılığı çoğaltma hedef tarafında tutarsız veritabanlarına yol açması. Veritabanı ve günlük ve yeniden oluşturma dosyaları genellikle olduğu gibi kaynak VM tarafında birden çok VHD'ye yayılırsa bu durum oluşur.

VM düğümüne karşı güvenlik

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

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

  • Aynı Azure bölgesinde ayrı bir kullanılabilirlik kümesinde iki VM dağıtın.
  • Bu iki VM'yi aynı Azure sanal ağına çalıştırın ve aynı alt ağların dışında NIC'lere sahip olun.
  • İkinci VM ile bir hazır bekleyen makineyi tutmak için veritabanı yöntemlerini kullanın. Yöntemler Always On SQL Server Oracle Data Guard veya HANA Sistem Çoğaltması ile kullanılabilir.

Ayrıca üçüncü bir VM'yi başka bir Azure bölgesinde dağıtabilirsiniz ve aynı veritabanı yöntemlerini kullanarak başka bir Azure bölgesinde zaman uyumsuz bir çoğaltma sebilirsiniz.

Azure kullanılabilirlik kümelerini ayarlama hakkında bilgi için bu öğreticiye bakın.

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, izinler ve kuruluş farklı bölümlerine yapılan rol atamaları için kullanın.

Bu en iyi yöntemler, yüzlerce müşteri dağıtımının sonucu olur:

  • SAP uygulamasının dağıtılacağı sanal ağların İnternet erişimi yok.
  • Veritabanı VM'leri, SAP uygulama katmanından farklı bir alt ağda ayrılmış olarak uygulama katmanıyla aynı sanal ağda çalıştırıldı.
  • Sanal ağ içindeki VM'ler, özel IP adresini statik olarak ayırmaya sahip olur. 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ı ile ayarlanmaz. Bunun yerine, trafik yönlendirmesi ağ güvenlik grupları (NSG) ile tanımlanır.
  • DBMS VM'si trafiğini ayırmak ve yalıtmak için VM'ye farklı NI'ler atarak. 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ı ayarlamak için kullanılamaz.

Not

Statik IP adreslerini Azure üzerinden atama, bunları tek tek sanal NIC'lere atama anlamına gelir. Konuk işletim sistemi içindeki statik IP adreslerini sanal bir NIC'ye atamayın. Azure Backup gibi bazı Azure hizmetleri, statik IP adreslerine değil, en azından birincil sanal NIC'nin DHCP'ye ayarlanmış olduğu gerçeğine güvenmektedir. Daha fazla bilgi için bkz. Azure sanal makine yedekleme sorunlarını giderme. Bir VM'ye birden çok statik IP adresi atamak için, bir VM'ye birden çok sanal GÜNCELLEŞTIRMESI attayabilirsiniz.

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ı desteklenmiyor. Bu kısıtlama işlevsellik ve performans nedenlerine yöneliktir. SAP uygulama katmanı ile DBMS katmanı arasındaki iletişim yolu doğrudan bir iletişim yolu olması gerekir. Bu ASG ve NSG kuralları doğrudan iletişim yoluna izin verdiyse, kısıtlama uygulama güvenlik grubunu (ASG) ve NSG kurallarını içermez.

Ağ sanal gereçlerini desteklemeen diğer senaryolar:

  • SUSE Linux Enterprise Server for SAP Applications üzerinde Azure VM'leri üzerinde SAP NetWeaveriçin yüksek kullanılabilirlik konusunda açıklandığı gibi Linux Pacemaker küme düğümlerini ve SBD cihazlarını temsil eden Azure VM'leri arasındaki iletişim yolları.
  • Azure VM'leri ile Windows Server Scale-Out Dosya Sunucusu (SOFS) arasındaki iletişim yolları, Azure'da bir dosya paylaşımı kullanarak bir Windows yük devretme kümesinde SAP ASCS/SCSörneği kümeleme konusunda açıklandığı gibi ayarlanır.

İletişim yollarında ağ sanal gereçleri, iki iletişim iş ortağı arasındaki ağ gecikme süresini kolayca iki katına çıkarabilir. Ayrıca SAP uygulama katmanı ile DBMS katmanı arasındaki kritik yollarda aktarım hızını kısıtlar. Bazı müşteri senaryolarında ağ sanal gereçleri Pacemaker Linux kümelerinde hataya neden olabilir. Bunlar, Linux Pacemaker küme düğümleri arasındaki iletişimin bir ağ sanal cihazı üzerinden SBD cihazıyla iletişim kurmasıdır.

Önemli

Desteklenen bir diğer tasarım da SAP uygulama katmanının ve DBMS katmanının, eşli olmayan farklı Azure sanal ağlarına ayrımı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 ayrı belirtmenizi öneririz.

Öneriyi izlemeyebilirsiniz ve bunun yerine iki katmanı farklı sanal ağlara yalıtabilirsiniz, iki sanal ağ eşlensin.

Eşli iki Azure sanal ağı arasındaki ağ trafiğinin aktarım maliyetlerine tabi olduğunu dikkat edin. Birçok terabayttan oluşan çok büyük veri hacmi, SAP uygulama katmanı ile DBMS katmanı arasında değişime neden olur. SAP uygulama katmanı ve DBMS katmanı eşlenmiş iki Azure sanal ağı arasında ayrı ayrı olursa önemli maliyetler elde edersiniz.

Bir Azure kullanılabilirlik kümesi içinde veya iki vm arasında üretim DBMS dağıtımınız için iki VM Azure Kullanılabilirlik Alanları. Ayrıca SAP uygulama katmanı için ayrı yönlendirme ve iki DBMS VM'ye yönelik yönetim ve işlem trafiği kullanın. Aşağıdaki resme bakın:

İki alt ağda yer alan iki VM'nin diyagramı

Trafiği yeniden Azure Load Balancer için Azure Load Balancer'i kullanma

SQL Server Always On veya HANA Sistem Çoğaltma gibi işlevlerde kullanılan özel sanal IP adreslerinin kullanımı, Azure yük dengeleyicinin yapılandırmasını gerektirir. 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ünde yük devretme varsa SAP uygulamasının yeniden yapılandırması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 karşı ikinci düğüme yönlendirerek düğüm yük devretmeye tepki gösterir.

Azure iki farklı yük dengeleyici SKU'susunar: temel bir SKU ve standart SKU. Kurulum ve işlevsellik avantajlarına bağlı olarak, Azure yük dengeleyicinin Standart SKU'larını kullanabilirsiniz. Yük dengeleyicinin Standart sürümünün büyük avantajlarından biri, veri trafiğinin yük dengeleyicinin kendisi üzerinden yönlendirilene sahip olmasıdır.

İç yük dengeleyici yapılandırma örneği Öğretici: Azure Sanal Makineler'de el ile SQL Server kullanılabilirlik grubu yapılandırma makalesinde bulunabilir

Not

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 yönelik çalışma yolu, SAP yüksek kullanılabilirlik senaryolarında Azure Standart Load Balancer kullanan Sanal Makineler için genel uç nokta bağlantısı belgesinde açıklanmıştır

Azure Hızlandırılmış Ağ

Azure VM'leri arasındaki ağ gecikme süresini daha da azaltmak için Azure Hızlandırılmış Ağ'ı seçmenizi öneririz. Özellikle SAP uygulama katmanı ve SAP DBMS katmanı için sap iş yükü için Azure VM'leri dağıtırken bunu kullanın.

Not

Tüm VM türleri Hızlandırılmış Ağı desteklemez. Önceki makalede Hızlandırılmış Ağ'ın desteklene VM türleri listelanmıştır.


Windows hızlandırılmış ağ oluşturma Windows

Windows için Hızlandırılmış Ağ ile VM'Windows dağıtma hakkında bilgi edinmek için bkz. Hızlandırılmış Ağ ile Windows sanal makine oluşturma.

Linux hızlandırılmış ağ Linux

Linux dağıtımı hakkında daha fazla bilgi için bkz. Hızlandırılmış Ağ ile Linux sanal makinesi oluşturma.


Not

SUSE, Red Hat ve Oracle Linux, Hızlandırılmış Ağ son sürümlerle birlikte de destek almaktadır. SLES 12 SP2 veya RHEL 7.2 gibi eski sürümler Azure Hızlandırılmış Ağ'ı desteklemez.

Konak izleme dağıtımı

SAP uygulamalarının Azure sanal makinelerde üretimde kullanımı için SAP, Azure sanal makinelerini çalıştıran fiziksel konaklardan konak izleme verilerini alabilmeyi gerektirir. SAPOSCOL ve SAP Host Agent'ta bu özelliği sağlayan belirli bir SAP Konak Aracısı düzeltme eki düzeyi gereklidir. Tam düzeltme eki düzeyi SAP [Note]1409604.

SAPOSCOL ve SAP Host Agent'a 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 dağıtım kılavuzuna bakın.

Sonraki adımlar

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