Azure'da SAP dağıtımı planlama ve uygulama

  • Makale

Azure'da kuruluşlar, uzun bir tedarik döngüsünü tamamlamadan ihtiyaç duydukları bulut kaynaklarını ve hizmetlerini alabilir. Ancak SAP iş yükünüzü Azure'da çalıştırmak için kullanılabilir seçenekler hakkında bilgi sahibi olmak ve çözümünüzü desteklemek için Azure bileşenlerini ve mimarisini seçmeyi dikkatli bir şekilde planlamanız gerekir.

Azure, SAP uygulamalarınızı çalıştırmak için kapsamlı bir platform sunar. Hizmet olarak Azure altyapısı (IaaS) ve hizmet olarak platform (PaaS) teklifleri, SAP kurumsal ortamınızın tamamında başarılı bir dağıtım için en uygun seçenekleri sunmak üzere bir araya getirir.

Bu makale, SAP yazılımının Azure'a ve diğer platformlara nasıl yükleneceği ve dağıtılacağı hakkında bilgi için birincil kaynaklar olan SAP belgelerini ve SAP Notlarını tamamlar.

Tanımlar

Bu makale boyunca aşağıdaki terimleri kullanırız:

  • SAP bileşeni: SAP S/4HANA, SAP ECC, SAP BW veya SAP Solution Manager gibi tek bir SAP uygulaması. SAP bileşeni, geleneksel Gelişmiş İş Uygulaması Programlama (ABAP) veya Java teknolojilerini temel alabilir veya SAP BusinessObjects gibi SAP NetWeaver tabanlı olmayan bir uygulama 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 gruplandırılmış birden çok SAP bileşeni.
  • SAP ortamı: Kuruluşun BT ortamındaki SAP varlıklarının tamamı. SAP ortamı tüm üretim ve üretim dışı ortamları içerir.
  • SAP sistemi: Veritabanı yönetim sistemi (DBMS) katmanı ile uygulama katmanının birleşimi. Bir SAP ERP geliştirme sistemi ve SAP BW test sistemi iki örnektir. Azure dağıtımında bu iki katman şirket içi ile Azure arasında dağıtılamaz. SAP sisteminin şirket içinde veya Azure'da dağıtılması gerekir. Ancak Azure'da veya şirket içinde SAP ortamı içinde farklı sistemler çalıştırabilirsiniz.

Kaynaklar

Azure'da SAP iş yükünü barındırmayı ve çalıştırmayı açıklayan belgelerin giriş noktası, Azure sanal makinesinde SAP kullanmaya başlama'dır. Makalede şunları kapsayan diğer makalelerin bağlantılarını bulabilirsiniz:

  • Depolama, ağ ve desteklenen seçenekler için SAP iş yükü özellikleri.
  • Azure'da çeşitli DBMS sistemleri için SAP DBMS kılavuzları.
  • Hem el ile hem de otomatik sap dağıtım kılavuzları.
  • Azure'da sap iş yükü için yüksek kullanılabilirlik ve olağanüstü durum kurtarma ayrıntıları.
  • Azure'da SAP ile diğer hizmetler ve üçüncü taraf uygulamalarla tümleştirme.

Önemli

Önkoşullar, yükleme işlemi ve belirli SAP işlevleriyle ilgili ayrıntılar için SAP belgelerini ve kılavuzlarını dikkatle okumak önemlidir. Bu makale yalnızca bir Azure sanal makinesine (VM) yüklenen ve çalıştırılan SAP yazılımlarına yönelik belirli görevleri kapsar.

Aşağıdaki SAP Notları, SAP dağıtımları için Azure kılavuzunun temelini oluşturur:

Not numarası Başlık
1928533 Azure'da SAP Uygulamaları: Desteklenen Ürünler ve Boyutlandırma
2015553 Azure'da SAP: Destek Önkoşulları
2039619 Oracle Veritabanı'nı kullanarak Azure'da SAP Uygulamaları
2233094 DB6: Linux, UNIX ve Windows için IBM Db2 Kullanarak Azure'da SAP Uygulamaları
1999351 SAP için Gelişmiş Azure İzleme sorunlarını giderme
1409604 Windows'ta Sanallaştırma: Gelişmiş İzleme
2191498 Azure ile Linux üzerinde SAP: Gelişmiş İzleme
2731110 Azure'da SAP için Ağ Sanal Gereçleri (NVA) desteği

Azure aboneliklerinin ve kaynaklarının genel varsayılan ve maksimum sınırlamaları için bkz . Azure aboneliği ve hizmet sınırları, kotalar ve kısıtlamalar.

Senaryolar

SAP hizmetleri genellikle bir kuruluştaki en görev açısından kritik uygulamalar arasında kabul edilir. Uygulamaların mimarisi ve işlemleri karmaşıktır ve kullanılabilirlik ve performans için tüm gereksinimlerin karşılandığından emin olmak önemlidir. Bir kuruluş genellikle iş açısından kritik iş süreçlerini çalıştırmak için hangi bulut sağlayıcısının seçileceğini dikkatli bir şekilde düşünür.

Azure, iş açısından kritik SAP uygulamaları ve iş süreçleri için ideal genel bulut platformudur. SAP NetWeaver ve SAP S/4HANA sistemleri dahil olmak üzere güncel SAP yazılımlarının çoğu bugün Azure altyapısında barındırılabilir. Azure, çok sayıda terabayt belleğe sahip 800'den fazla CPU türü ve VM sunar.

Desteklenen senaryoların ve desteklenmeyen bazı senaryoların açıklamaları için bkz . Azure VM'lerinde SAP desteklenen senaryolar. Azure'a dağıtmak istediğiniz mimariyi planladığınızda bu senaryoları ve desteklenmediği belirtilen koşulları denetleyin.

SAP sistemlerini Azure IaaS'ye veya genel olarak IaaS'ye başarıyla dağıtmak için, geleneksel özel bulutların teklifleri ile IaaS teklifleri arasındaki önemli farkları anlamak önemlidir. Geleneksel bir konak veya dış kaynak, altyapıyı (ağ, depolama ve sunucu türü) müşterinin barındırmak istediği iş yüküne uyarlar. IaaS dağıtımında, potansiyel iş yüklerini değerlendirmek ve VM'lerin, depolamanın ve ağın doğru Azure bileşenlerini seçmek müşterinin veya iş ortağının sorumluluğundadır.

Azure'a dağıtımınızı planlamak için veri toplamak için şunları yapmak önemlidir:

  • Azure'da hangi SAP ürünlerinin ve sürümlerinin destekleneceğini belirleyin.
  • Kullanmayı planladığınız işletim sistemi sürümlerinin SAP ürünleriniz için seçtiğiniz Azure VM'lerinde desteklenip desteklenmediğini değerlendirin.
  • SAP ürünleriniz için belirli VM'lerdeki hangi DBMS sürümlerinin destekleneceğini belirleyin.
  • Desteklenen bir yapılandırmaya ulaşmak için gerekli işletim sistemi ve DBMS sürümleriyle uyumlu hale getirmek için SAP ortamınızı yükseltmenin veya güncelleştirmenin gerekli olup olmadığını değerlendirin.
  • Azure'da dağıtmak için farklı işletim sistemlerine geçmeniz gerekip gerekmediğini değerlendirin.

Azure'da desteklenen SAP bileşenleri, Azure altyapı birimleri ve ilgili işletim sistemi sürümleri ve DBMS sürümleri hakkındaki ayrıntılar, Azure dağıtımları için desteklenen SAP yazılımında açıklanmıştır. SAP sürümleri, işletim sistemi sürümleri ve DBMS sürümleri arasındaki destek ve bağımlılıkları değerlendirerek elde ettiğiniz bilgiler, SAP sistemlerinizi Azure'a taşıma çabalarınızı önemli ölçüde etkiler. Önemli hazırlık çalışmalarının söz konusu olup olmadığını, örneğin SAP sürümünüzü yükseltmeniz mi yoksa farklı bir işletim sistemine mi geçmeniz gerektiğini öğrenirsiniz.

Dağıtım planlamanın ilk adımları

Dağıtım planlamasının ilk adımı, SAP uygulamalarını çalıştırmak için kullanılabilen VM'leri aramak değildir.

Dağıtımı planlamanın ilk adımları, genel buluta hangi tür SAP iş yükü veya iş süreci dağıtmak için sınır koşullarını belirlemek üzere kuruluşunuzdaki uyumluluk ve güvenlik ekipleriyle çalışmaktır. İşlem zaman alabilir ancak tamamlanması kritik öneme sahiptir.

Kuruluşunuz Azure'da zaten yazılım dağıttıysa işlem kolay olabilir. Şirketiniz yolculuğun başında daha fazlaysa, belirli SAP verilerinin ve SAP iş süreçlerinin genel bulutta barındırılmasına olanak tanıyan sınır koşullarını, güvenlik koşullarını ve kurumsal mimariyi bulmak için daha büyük tartışmalar gerekebilir.

Uyumluluk planı

Uyumluluk gereksinimlerinizi planlamanıza yardımcı olabilecek Microsoft uyumluluk tekliflerinin listesi için bkz . Microsoft uyumluluk teklifleri.

Güvenlik için plan

Bekleyen veriler için veri şifreleme veya bir Azure hizmetindeki diğer şifreleme gibi SAP'ye özgü güvenlik endişeleri hakkında bilgi için bkz . Azure şifrelemeye genel bakış ve SAP ortamınız için güvenlik.

Azure kaynaklarını düzenleme

Güvenlik ve uyumluluk gözden geçirmesiyle birlikte, bu görevi henüz yapmadıysanız Azure kaynaklarınızı nasıl düzenlediğinizi planlayın. Bu süreç şunlarla ilgili kararlar almayı içerir:

  • Vm'ler ve kaynak grupları gibi her Azure kaynağı için kullandığınız adlandırma kuralı.
  • SAP iş yükünüz için, iş yükü başına, dağıtım katmanı başına veya her bir iş birimi için birden çok abonelik oluşturulması gerekip gerekmediği gibi bir abonelik ve yönetim grubu tasarımı.
  • Abonelikler ve yönetim grupları için kuruluş genelinde Azure İlkesi kullanımı.

Doğru kararları vermenize yardımcı olmak için, Kurumsal mimarinin birçok ayrıntısı Azure Bulut Benimseme Çerçevesi'nde açıklanmıştır.

Planlamanızda projenin ilk aşamasını hafife almayın. Yalnızca uyumluluk, güvenlik ve Azure kaynak organizasyonu için sözleşmeleriniz ve kurallarınız varsa dağıtım planlamanızı ilerletmelisiniz.

Sonraki adımlar coğrafi yerleştirmeyi ve Azure'da dağıttığınız ağ mimarisini planlamaktır.

Azure coğrafyaları ve bölgeleri

Azure hizmetleri ayrı Azure bölgelerinde kullanılabilir. Azure bölgesi, veri merkezlerinden oluşan bir koleksiyondur. Veri merkezleri, bölgede kullanılabilen Azure hizmetlerini barındıran ve çalıştıran donanım ve altyapıyı içerir. Altyapı, işlem düğümleri veya depolama düğümleri olarak çalışan veya ağ işlevselliğini çalıştıran çok sayıda düğüm içerir.

Azure bölgelerinin listesi için bkz . Azure coğrafyaları. Etkileşimli bir harita için bkz . Azure genel altyapısı.

Tüm Azure bölgeleri aynı hizmetleri sunmaz. Çalıştırmak istediğiniz SAP ürününe, boyutlandırma gereksinimlerinize ve ihtiyacınız olan işletim sistemine ve DBMS'ye bağlı olarak, belirli bir bölge senaryonuz için gerekli VM türlerini sunmamış olabilir. Örneğin, SAP HANA çalıştırıyorsanız, genellikle çeşitli M serisi VM ailelerinin VM'lerine ihtiyacınız vardır. Bu VM aileleri, Azure bölgelerinin yalnızca bir alt kümesinde dağıtılır.

Birincil bölge ve sonunda ikincil bölge olarak hangi bölgelerin seçileceğini planlamaya ve düşünmeye başladığınızda, senaryolarınız için ihtiyacınız olan hizmetlerin göz önünde bulundurduğunuz bölgelerde kullanılabilir olup olmadığını araştırmanız gerekir. Bölgelere göre kullanılabilir ürünler bölümünde her bölgede hangi VM türlerinin, Azure depolama türlerinin ve diğer Azure hizmetlerinin kullanılabilir olduğunu tam olarak öğrenebilirsiniz.

Azure eşleştirilmiş bölgeleri

Eşleştirilmiş bir Azure bölgesinde, iki bölge arasında belirli verilerin çoğaltması varsayılan olarak etkinleştirilir. Daha fazla bilgi için bkz . Azure'da bölgeler arası çoğaltma: İş sürekliliği ve olağanüstü durum kurtarma.

Bölge çiftindeki veri çoğaltma, eşleştirilmiş bir bölgeye çoğaltmak için yapılandırabileceğiniz Azure depolama türlerine bağlıdır. Ayrıntılar için bkz. İkincil bölgede yedeklilik Depolama.

Eşleştirilmiş bölge veri çoğaltmasını destekleyen depolama türleri, SAP bileşenleri ve DBMS iş yükü için uygun olmayan depolama türleridir. Azure depolama çoğaltmasının kullanılabilirliği Azure Blob Depolama (yedekleme amacıyla), dosya paylaşımları ve birimlerle ve diğer yüksek gecikme süreli depolama senaryolarıyla sınırlıdır.

Eşleştirilmiş bölgeleri ve birincil veya ikincil bölgelerinizde kullanmak istediğiniz hizmetleri denetlerken, birincil bölgenizde kullanmayı planladığınız Azure hizmetleri veya VM türlerinin ikincil bölge olarak kullanmak istediğiniz eşleştirilmiş bölgede kullanılamamış olması mümkündür. Alternatif olarak, veri uyumluluğu nedenleriyle senaryonuz için Azure eşleştirilmiş bir bölgenin kabul edilebilir olmadığını belirleyebilirsiniz. Bu senaryolarda, istenmeyen bir bölgeyi ikincil veya olağanüstü durum kurtarma bölgesi olarak kullanmanız ve veri çoğaltmasının bir kısmını kendiniz ayarlamanız gerekir.

Kullanılabilirlik alanları

Birçok Azure bölgesi, bir Azure bölgesi içindeki konumları fiziksel olarak ayırmak için kullanılabilirlik alanlarını kullanır. Her kullanılabilirlik alanı bağımsız güç, soğutma ve ağ ile donatılmış bir veya daha fazla veri merkezinden oluşur. Dayanıklılığı artırmak için kullanılabilirlik alanı kullanmanın bir örneği, Azure'da iki ayrı kullanılabilirlik alanına iki VM dağıtmaktır. Bir diğer örnek de SAP DBMS sisteminiz için bir kullanılabilirlik alanında yüksek kullanılabilirlik çerçevesi uygulamak ve SAP (A)SCS'yi başka bir kullanılabilirlik alanına dağıtarak Azure'daki en iyi SLA'yı elde etmektir.

Azure'daki VM SLA'ları hakkında daha fazla bilgi için Sanal Makineler SLA'ların en son sürümünü gözden geçirin. Azure bölgeleri hızla geliştirilip genişlediğinden, Azure bölgelerinin topolojisi, fiziksel veri merkezlerinin sayısı, veri merkezleri arasındaki mesafe ve Azure kullanılabilirlik alanları arasındaki mesafe gelişir. Altyapı değiştikçe ağ gecikme süresi değişiklikleri.

Kullanılabilirlik alanları olan bir bölge seçtiğinizde Azure kullanılabilirlik alanlarıyla SAP iş yükü yapılandırmaları bölümünde yer alan yönergeleri izleyin. Ayrıca gereksinimleriniz, seçtiğiniz bölge ve iş yükünüz için en uygun olan bölgesel dağıtım modelini belirleyin.

Hata etki alanları

Hata etki alanları fiziksel bir hata birimini temsil eder. Hata etki alanı, veri merkezlerinde bulunan fiziksel altyapıyla yakından ilgilidir. Fiziksel bir dikey pencere veya raf hata etki alanı olarak kabul edilebilir ancak fiziksel bilgi işlem öğesi ile hata etki alanı arasında doğrudan bire bir eşleme yoktur.

Bir SAP sisteminin parçası olarak birden çok VM dağıttığınızda, kullanılabilirlik SLA'ları gereksinimlerini karşılayabilmeniz için VM'lerinizi farklı hata etki alanlarına dağıtmak için Azure doku denetleyicisini dolaylı olarak etkileyebilirsiniz. Ancak, azure ölçek birimi (yüzlerce işlem düğümü veya depolama düğümü ve ağ koleksiyonu) üzerinden hata etki alanlarının dağıtımı veya vm'lerin belirli bir hata etki alanına atanması üzerinde doğrudan denetiminiz yoktur. Azure doku denetleyicisini farklı hata etki alanları üzerinden vm kümesi dağıtmak üzere manevra yapmak için, dağıtım zamanında VM'lere bir Azure kullanılabilirlik kümesi atamanız gerekir. Daha fazla bilgi için bkz . Kullanılabilirlik kümeleri.

Güncelleme etki alanları

Güncelleştirme etki alanları, birden çok VM'den oluşan sap sistemindeki bir VM'nin nasıl güncelleştirildiğini ayarlayan mantıksal bir birimi temsil eder. Bir platform güncelleştirmesi gerçekleştiğinde Azure, bu güncelleştirme etki alanlarını tek tek güncelleştirme işleminden geçer. VM'leri dağıtım zamanında farklı güncelleştirme etki alanlarına yayarak SAP sisteminizi olası kapalı kalma süresine karşı koruyabilirsiniz. Hata etki alanlarına benzer şekilde, azure ölçek birimi birden çok güncelleştirme etki alanına ayrılır. Azure doku denetleyicisini farklı güncelleştirme etki alanları üzerinden vm kümesi dağıtmak üzere manevra yapmak için, dağıtım zamanında VM'lere bir Azure kullanılabilirlik kümesi atamanız gerekir. Daha fazla bilgi için bkz . Kullanılabilirlik kümeleri.

Diagram that depicts update domains and failure domains.

Kullanılabilirlik kümeleri

Bir Azure kullanılabilirlik kümesindeki Azure VM'leri, Azure doku denetleyicisi tarafından farklı hata etki alanları üzerinden dağıtılır. Farklı hata etki alanları üzerindeki dağıtım, bir SAP sisteminin tüm VM'lerinin altyapı bakımı sırasında veya bir hata etki alanında hata oluşması durumunda kapatılmasını önlemektir. Vm'ler varsayılan olarak bir kullanılabilirlik kümesinin parçası değildir. Kullanılabilirlik kümesinde vm'yi yalnızca dağıtım zamanında veya vm yeniden dağıtıldığında ekleyebilirsiniz.

Azure kullanılabilirlik kümeleri ve kullanılabilirlik kümelerinin hata etki alanlarıyla ilişkisi hakkında daha fazla bilgi edinmek için bkz . Azure kullanılabilirlik kümeleri.

Önemli

Azure'daki kullanılabilirlik alanları ve kullanılabilirlik kümeleri birbirini dışlar. Belirli bir kullanılabilirlik alanına veya bir kullanılabilirlik kümesine birden çok VM dağıtabilirsiniz. Ancak hem kullanılabilirlik alanı hem de kullanılabilirlik kümesi vm'ye atanabilir.

Yakınlık yerleştirme gruplarını kullanıyorsanız kullanılabilirlik kümelerini ve kullanılabilirlik alanlarını birleştirebilirsiniz.

Kullanılabilirlik kümelerini tanımlarken ve bir kullanılabilirlik kümesinde farklı VM ailelerinin çeşitli VM'lerini karıştırmaya çalışırken, belirli bir VM türünü bir kullanılabilirlik kümesine eklemenizi engelleyen sorunlarla karşılaşabilirsiniz. Bunun nedeni, kullanılabilirlik kümesinin belirli bir işlem konağı türü içeren bir ölçek birimine bağlı olmasıdır. Belirli bir işlem konağı türü yalnızca belirli vm ailesi türlerinde çalıştırılabilir.

Örneğin, bir kullanılabilirlik kümesi oluşturur ve kullanılabilirlik kümesindeki ilk VM'yi dağıtırsınız. Kullanılabilirlik kümesine eklediğiniz ilk VM, Edsv5 VM ailesindedir. M ailesindeki bir VM olan ikinci bir VM'yi dağıtmaya çalıştığınızda bu dağıtım başarısız olur. Bunun nedeni, Edsv5 ailesi VM'lerinin M ailesindeki VM'lerle aynı konak donanımında çalışmamasıdır.

VM'leri yeniden boyutlandırıyorsanız aynı sorun oluşabilir. Bir VM'yi Edsv5 ailesinden ve M ailesindeki bir VM türüne taşımaya çalışırsanız dağıtım başarısız olur. Aynı konak donanımında barındırılamayacak bir VM ailesine yeniden boyutlandırırsanız, kullanılabilirlik kümenizdeki tüm VM'leri kapatmanız ve diğer konak makine türünde çalışabilmek için tümünü yeniden boyutlandırmanız gerekir. Kullanılabilirlik kümesinde dağıtılan VM'lerin SLA'ları hakkında bilgi için bkz. Sanal Makineler SLA'lar.

Esnek düzenleme ile sanal makine ölçek kümeleri

Esnek düzenlemeye sahip sanal makine ölçek kümeleri , platform tarafından yönetilen sanal makinelerin mantıksal gruplandırmalarını sağlar. Bölge içinde ölçek kümesi oluşturma veya kullanılabilirlik alanlarına yayma seçeneğiniz vardır. Oluşturma sırasında platformFaultDomainCount>1 (FD>1) içeren bir bölge içindeki esnek ölçek kümesi, ölçek kümesinde dağıtılan VM'ler aynı bölgedeki belirtilen sayıda hata etki alanına dağıtılır. Öte yandan platformFaultDomainCount=1 (FD=1) ile kullanılabilirlik alanları arasında esnek ölçek kümesi oluşturmak VM'leri belirtilen bölgeye dağıtacak ve ölçek kümesi de vm'leri bölge içindeki farklı hata etki alanları arasında en iyi çaba temelinde dağıtacaktı.

SAP iş yükü için yalnızca FD=1 ile esnek ölçek kümesi desteklenir. Geleneksel kullanılabilirlik alanı dağıtımı yerine FD=1 ile esnek ölçek kümelerini FD=1 ile kullanmanın avantajı, ölçek kümesiyle dağıtılan VM'lerin bölge içindeki farklı hata etki alanlarına en iyi çabayla dağıtılmasıdır. Ölçek kümesi ile SAP iş yükü dağıtımı hakkında daha fazla bilgi edinmek için bkz . Esnek sanal makine ölçek dağıtımı kılavuzu.

Azure'da yüksek kullanılabilirliğe sahip bir SAP iş yükü dağıtırken, kullanılabilen çeşitli dağıtım türlerini ve bunların farklı Azure bölgelerinde (bölgeler arasında, tek bir bölgede veya bölgeleri olmayan bir bölgede) nasıl uygulanabileceğini dikkate almak önemlidir. Daha fazla bilgi için bkz . SAP iş yükü için yüksek kullanılabilirlik dağıtım seçenekleri.

Bahşiş

Şu anda kullanılabilirlik kümelerinde veya Kullanılabilirlik alanlarında dağıtılan SAP iş yükünü FD=1 ile esnek ölçeğe geçirmenin doğrudan bir yolu yoktur. Geçiş yapmak için vm ve diski mevcut kaynaklardan gelen bölge kısıtlamalarıyla yeniden oluşturmanız gerekir. Açık kaynak projesi , kullanılabilirlik kümesinde veya kullanılabilirlik alanında dağıtılan bir VM'yi FD=1 ile esnek ölçek kümesine değiştirmek için örnek olarak kullanabileceğiniz PowerShell işlevlerini içerir. Bir blog gönderisi , kullanılabilirlik kümesinde veya kullanılabilirlik alanında dağıtılan bir HA veya HA olmayan SAP sistemini FD=1 ile esnek ölçek kümesine nasıl değiştirebileceğinizi gösterir.

Yakınlık yerleştirme grupları

Tek tek SAP VM'leri arasındaki ağ gecikme süresinin performans açısından önemli etkileri olabilir. ÖZELLIKLE SAP uygulama sunucuları ile DBMS arasındaki ağ gidiş dönüş süresi, iş uygulamalarını önemli ölçüde etkileyebilir. En uygun şekilde, SAP VM'lerinizi çalıştıran tüm işlem öğeleri mümkün olduğunca yakından bulunur. Bu seçenek her birleşimde mümkün değildir ve Azure hangi VM'lerin bir arada tutulabileceğini bilmiyor olabilir. Çoğu durumda ve bölgede varsayılan yerleştirme, ağ gidiş dönüş gecikme süresi gereksinimlerini karşılar.

Varsayılan yerleştirme bir SAP sistemi içindeki ağ gidiş dönüş gereksinimlerini karşılamadığında, yakınlık yerleştirme grupları bu gereksinimi karşılayabilir. Dayanıklılığı artırmak için Azure bölgesinin, kullanılabilirlik alanının ve kullanılabilirlik kümesinin konum kısıtlamalarıyla yakınlık yerleştirme gruplarını kullanabilirsiniz. Yakınlık yerleştirme grubuyla, farklı güncelleştirme ve hata etki alanlarını ayarlarken hem kullanılabilirlik alanını hem de kullanılabilirlik kümesini birleştirmek mümkündür. Yakınlık yerleştirme grubu yalnızca tek bir SAP sistemi içermelidir.

Yakınlık yerleştirme grubundaki dağıtımın gecikme süresi en iyi duruma getirilmiş yerleştirmeye neden olmasına rağmen, yakınlık yerleştirme grubu kullanarak dağıtmanın da dezavantajları vardır. Bazı VM aileleri tek bir yakınlık yerleştirme grubunda birleştirilemiyor veya VM aileleri arasında yeniden boyutlandırma yaparsanız sorunlarla karşılaşabilirsiniz. VM ailelerinin, bölgelerinin ve kullanılabilirlik alanlarının kısıtlamaları birlikte bulundurmayı desteklemeyebilir. Ayrıntılar ve yakınlık yerleştirme grubu kullanmanın avantajları ve olası zorlukları hakkında bilgi edinmek için bkz . Yakınlık yerleştirme grubu senaryoları.

Yakın yerleştirme gruplarını kullanmayan VM'ler, SAP sistemleri için çoğu durumda varsayılan dağıtım yöntemi olmalıdır. Bu varsayılan özellikle bir SAP sisteminin bölgesel (tek bir kullanılabilirlik alanı) ve çapraz bölge (iki kullanılabilirlik alanı arasında dağıtılan VM'ler) dağıtımları için geçerlidir. Yakınlık yerleştirme gruplarının kullanılması, yalnızca performans nedeniyle gerektiğinde SAP sistemleri ve Azure bölgeleriyle sınırlı olmalıdır.

Azure ağı

Azure,SAP dağıtımında uygulamak isteyebileceğiniz tüm senaryolara eşleyen bir ağ altyapısına sahiptir. Azure'da aşağıdaki özelliklere sahipsiniz:

  • Azure hizmetlerine erişim ve uygulamaların kullandığı VM'lerdeki belirli bağlantı noktalarına erişim.
  • Yönetim ve yönetim için Secure Shell (SSH) veya Windows Uzak Masaüstü (RDP) aracılığıyla VM'lere doğrudan erişim.
  • VM'ler ve Azure hizmetleri arasındaki iç iletişim ve ad çözümlemesi.
  • Şirket içi ağ ile Azure ağları arasında şirket içi bağlantı.
  • Farklı Azure bölgelerinde dağıtılan hizmetler arasındaki iletişim.

Ağ hakkında ayrıntılı bilgi için bkz. Azure Sanal Ağ.

Ağ tasarımı genellikle Azure'a dağıttığınızda gerçekleştirdiğiniz ilk teknik etkinliktir. SAP gibi merkezi bir kurumsal mimariyi sık sık desteklemek, genel ağ gereksinimlerinin bir parçasıdır. Planlama aşamasında, önerilen ağ mimarisini mümkün olduğunca ayrıntılı olarak belgelemeniz gerekir. Alt ağ adresini değiştirme gibi sonraki bir noktada değişiklik yaparsanız, dağıtılan kaynakları taşımanız veya silmeniz gerekebilir.

Azure sanal ağları

Sanal ağ, Azure'daki özel ağınız için temel bir yapı taşıdır. Ağın adres aralığını tanımlayabilir ve aralığı ağ alt ağlarına ayırabilirsiniz. Bir SAP VM'nin kullanması için bir ağ alt ağı kullanılabilir veya belirli bir hizmete veya amaca ayrılmış olabilir. Azure Sanal Ağ ve Azure Uygulaması lication Gateway gibi bazı Azure hizmetleri ayrılmış bir alt ağ gerektirir.

Sanal ağ, ağ sınırı işlevi görür. Dağıtımınızı planlarken gerekli olan tasarımın bir bölümü sanal ağı, alt ağları ve özel ağ adres aralıklarını tanımlamaktır. VM'ler dağıtıldıktan sonra VM'ler için ağ arabirim kartları (NIC) gibi kaynaklar için sanal ağ atamasını değiştiremezsiniz. Sanal ağda veya alt ağ adres aralığında değişiklik yapmak, dağıtılan tüm kaynakları farklı bir alt ağa taşımanızı gerektirebilir.

Ağ tasarımınız SAP dağıtımı için çeşitli gereksinimleri karşılamalıdır:

  • S/4HANA veya SAP NetWeaver gibi SAP çekirdeği aracılığıyla SAP uygulaması ile SAP ürünlerinin DBMS katmanı arasındaki iletişim yoluna güvenlik duvarı gibi ağ sanal gereçleri yerleştirilmemiştir.
  • Ağ yönlendirme kısıtlamaları, alt ağ düzeyindeki ağ güvenlik grupları (NSG) tarafından uygulanır. VM'lerin IP'lerini NSG kurallarında tutulan uygulama güvenlik grupları (ASG) olarak gruplandırın ve izinlerin rol, katman ve SID gruplandırmalarını sağlayın.
  • SAP uygulaması ve veritabanı VM'leri aynı sanal ağda, tek bir sanal ağın aynı veya farklı alt ağlarında çalışır. Uygulama ve veritabanı VM'leri için farklı alt ağlar kullanın. Alternatif olarak, aynı alt ağ içindeki her iş yükü türü için geçerli olan kuralları gruplandırmak için ayrılmış uygulama ve DBMS ASG'leri kullanın.
  • Hızlandırılmış ağ, teknik olarak mümkün olduğunda SAP iş yükleri için tüm VM'lerin tüm ağ kartlarında etkinleştirilir.
  • Ad çözümleme (DNS), kimlik yönetimi (Windows Server Active Directory etki alanları/Microsoft Entra Id) ve yönetim erişimi dahil olmak üzere merkezi hizmetlere bağımlılık için güvenli erişim sağlayın.
  • Gerektiğinde genel uç noktalara ve bu uç noktalara erişim sağlayın. Örnekler arasında ClusterLabs Pacemaker işlemleri için yüksek kullanılabilirlik veya Azure Backup gibi Azure hizmetleri için Azure yönetimi verilebilir.
  • Birden çok NIC'yi yalnızca kendi yolları ve NSG kuralları olan belirlenmiş alt ağlar oluşturmak için gerekliyse kullanın.

SAP dağıtımı için ağ mimarisi örnekleri için aşağıdaki makalelere bakın:

Sanal ağ konusunda dikkat edilmesi gerekenler

Bazı sanal ağ yapılandırmalarında dikkat edilmesi gereken belirli noktalar vardır.

  • S/4HANA veya SAP NetWeaver gibi SAP çekirdeğini kullanarak SAP uygulama katmanı ile SAP bileşenlerinin DBMS katmanı arasındaki iletişim yolunda ağ sanal gereçlerinin yapılandırılması desteklenmez.

    İ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ı senaryolarda ağ sanal gereçleri Pacemaker Linux kümelerinin başarısız olmasına neden olabilir.

    SAP uygulama katmanı ile DBMS katmanı arasındaki iletişim yolu doğrudan bir yol olmalıdır. ASG ve NSG kuralları doğrudan iletişim yoluna izin veriyorsa kısıtlama ASG ve NSG kurallarını içermez.

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

  • SAP uygulama katmanını ve DBMS katmanını farklı Azure sanal ağlarına ayırmak desteklenmez. SAP uygulama katmanını ve DBMS katmanını farklı Azure sanal ağları yerine aynı Azure sanal ağı içindeki alt ağları kullanarak ayırmanızı öneririz.

    Farklı sanal ağlarda iki SAP sistem katmanını ayıran desteklenmeyen bir senaryo ayarlarsanız, iki sanal ağın eşlenmiş olmasıgerekir.

    eşlenmiş iki Azure sanal ağı arasındaki ağ trafiği aktarım maliyetlerine tabidir. Her gün, SAP uygulama katmanı ile DBMS katmanı arasında çok sayıda terabayttan oluşan çok büyük miktarda veri alışverişi yapılır. SAP uygulama katmanı ve DBMS katmanı eşlenmiş iki Azure sanal ağı arasında ayrılmışsa önemli maliyetler doğurabilirsiniz.

Ad çözümlemesi ve etki alanı hizmetleri

ANA bilgisayar adını DNS aracılığıyla IP adresine çözümlemek genellikle SAP ağı için önemli bir öğedir. Azure'da ad ve IP çözümlemesini yapılandırmak için birçok seçeneğiniz vardır.

Genellikle bir kuruluş, genel mimarinin parçası olan merkezi bir DNS çözümüne sahiptir. Kendi DNS sunucularınızı ayarlamak yerine Azure'da yerel olarak ad çözümlemesi uygulamak için çeşitli seçenekler, Azure sanal ağlarındaki kaynaklar için ad çözümlemesi bölümünde açıklanmıştır.

DNS hizmetlerinde olduğu gibi, Windows Server Active Directory'nin SAP VM'leri veya hizmetleri tarafından erişilebilir olması gerekebilir.

IP adresi ataması

Bir NIC'nin IP adresi, BIR VM'nin NIC'sinin varlığı boyunca talep edilen ve kullanılan kalır. Kural hem dinamik hem de statik IP ataması için geçerlidir. VM'nin çalışıp çalışmadığı veya kapatılıp kapatılmadığı doğru kalır. NIC silinirse, alt ağ değişirse veya ayırma yöntemi statik olarak değişirse dinamik IP ataması serbest bırakılır.

Azure sanal ağı içindeki VM'lere sabit IP adresleri atamak mümkündür. IP adresleri genellikle dış DNS sunucularına ve statik girişlere bağımlı SAP sistemleri için yeniden atanır. VM ve NIC'si silinene kadar veya IP adresi atanmayana kadar IP adresi atanmış olarak kalır. Sanal ağ için IP adresi aralığını tanımlarken VM'lerin genel sayısını (çalışan ve durdurulan) dikkate almanız gerekir.

Daha fazla bilgi için bkz . Statik özel IP adresine sahip bir VM oluşturma.

Dekont

Azure VM'leri ve NIC'leri için statik ve dinamik IP adresi ayırma arasında karar vermelisiniz. VM'nin konuk işletim sistemi, VM ön başlatıldığında NIC'ye atanan IP'yi alır. Konuk işletim sistemindeki statik IP adreslerini bir NIC'ye atamamalısınız. Azure Backup gibi bazı Azure hizmetleri, işletim sistemi içindeki statik IP adreslerine değil, en azından birincil NIC'nin DHCP olarak ayarlanmasına dayanır. Daha fazla bilgi için bkz . Azure VM yedekleme sorunlarını giderme.

SAP ana bilgisayar adı sanallaştırması için ikincil IP adresleri

Her Azure VM'nin NIC'sine atanmış birden çok IP adresi olabilir. İkincil IP, BIR DNS A kaydına veya DNS PTR kaydına eşlenen BIR SAP sanal ana bilgisayar adı için kullanılabilir. Azure NIC'nin IP yapılandırmasına ikincil bir IP adresi atanmalıdır. İkincil IP'ler genellikle DHCP aracılığıyla atanmadığından, ikincil IP'lerin de işletim sistemi içinde statik olarak yapılandırılması gerekir. Her ikincil IP, NIC'nin bağlı olduğu alt ağdan olmalıdır. vm durdurulmadan veya serbest bırakılmadan bir Azure NIC'den ikincil IP eklenebilir ve kaldırılabilir. Bir NIC'nin birincil IP'sini eklemek veya kaldırmak için VM'nin serbest bırakılması gerekir.

Dekont

İkincil IP yapılandırmalarında Azure yük dengeleyicinin kayan IP adresi desteklenmez. Azure yük dengeleyici, Pacemaker kümelerine sahip SAP yüksek kullanılabilirlik mimarileri tarafından kullanılır. Bu senaryoda yük dengeleyici SAP sanal konak adlarını etkinleştirir. Sanal konak adlarını kullanma hakkında genel yönergeler için bkz. SAP Not 962955.

SAP çalıştıran VM'ler ile Azure Load Balancer

Yük dengeleyici genellikle etkin ve pasif küme düğümleri arasında kayan IP adresleri sağlamak için yüksek kullanılabilirlik mimarilerinde kullanılır. Bir SAP sanal ana bilgisayar adının sanal IP adresini tutmak için tek bir VM için yük dengeleyici de kullanabilirsiniz. Tek bir VM için yük dengeleyici kullanmak, bir NIC üzerinde ikincil IP adresi kullanmaya veya aynı alt ağda birden çok NIC kullanmaya alternatiftir.

Standart yük dengeleyici, mimarisi varsayılan olarak güvenli olduğundan varsayılan giden erişim yolunu değiştirir. Standart yük dengeleyicinin arkasındaki VM'ler artık aynı genel uç noktalara ulaşamayabilir. Bazı örnekler, bir işletim sistemi güncelleştirme deposu veya Azure hizmetlerinin genel uç noktası için bir uç noktadır. Giden bağlantı sağlama seçenekleri için bkz . Azure standart yük dengeleyiciyi kullanarak VM'ler için genel uç nokta bağlantısı.

Bahşiş

Temel yük dengeleyici, Azure'daki herhangi bir SAP mimarisiyle kullanılmamalıdır. Temel yük dengeleyici kullanımdan kaldırılacak şekilde zamanlanmıştır.

VM başına birden çok vNIC

Her vNIC birincil vNIC ile aynı sanal ağdaki herhangi bir alt ağa atanmış bir Azure VM için birden çok sanal ağ arabirimi kartı (vNIC) tanımlayabilirsiniz. Birden çok vNIC'ye sahip olma özelliği sayesinde, gerekirse ağ trafiği ayrımını ayarlamaya başlayabilirsiniz. Örneğin, istemci trafiği birincil vNIC üzerinden yönlendirilir ve bazı yönetici veya arka uç trafiği ikinci bir vNIC üzerinden yönlendirilir. kullandığınız işletim sistemine ve görüntüye bağlı olarak, işletim sistemi içindeki NIC'ler için trafik yollarının doğru yönlendirme için ayarlanması gerekebilir.

Vm'nin türü ve boyutu, bir VM'nin kaç vNIC atayabileceğini belirler. İşlevsellik ve kısıtlamalar hakkında bilgi için bkz . Azure portalını kullanarak VM'lere birden çok IP adresi atama.

Vm'ye vNIC eklemek kullanılabilir ağ bant genişliğini artırmaz. Tüm ağ arabirimleri aynı bant genişliğini paylaşır. Yalnızca VM'lerin özel alt ağlara erişmesi gerekiyorsa birden çok NIC kullanmanızı öneririz. NSG işlevselliğine dayalı ve ağ ve alt ağ gereksinimlerini basitleştiren bir tasarım deseni öneririz. Tasarımda mümkün olduğunca az ağ arabirimi ve en uygun şekilde yalnızca bir arabirim kullanılmalıdır. HaNA iç ağı için ikincil bir vNIC'nin gerekli olduğu HANA ölçeği genişletme özel durumudur.

Uyarı

Vm'de birden çok vNIC kullanıyorsanız, kullanıcı ağ trafiğini işlemek için birincil NIC'nin alt ağını kullanmanızı öneririz.

Hızlandırılmış ağ

Azure VM'leri arasındaki ağ gecikme süresini daha da azaltmak için, SAP iş yükü çalıştıran her VM'de Azure hızlandırılmış ağ özelliğinin etkinleştirildiğini onaylamanızı öneririz. Hızlandırılmış ağ yeni VM'ler için varsayılan olarak etkin olsa da dağıtım denetim listesi başına durumu doğrulamanız gerekir. Hızlandırılmış ağ oluşturmanın avantajları, ağ performansını ve gecikme sürelerini büyük ölçüde geliştirmektir. Sap iş yükleri için Azure VM'lerini, özellikle SAP uygulama katmanı ve SAP DBMS katmanı için desteklenen tüm VM'lere dağıtırken kullanın. Bağlantılı belgelerde işletim sistemi sürümleri ve VM örneklerine yönelik destek bağımlılıkları yer alır.

Şirket içi bağlantı

Azure'da SAP dağıtımı, şirket içi bağlantıyı etkinleştirmek için merkezi, kuruluş genelinde bir ağ mimarisi ve iletişim hub'ı olduğunu varsayar. Şirket içi ağ bağlantısı, kullanıcıların ve uygulamaların merkezi DNS, etki alanı, güvenlik ve düzeltme eki yönetimi altyapısı gibi diğer merkezi kuruluş hizmetlerine erişmek için Azure'daki SAP ortamına erişmesine olanak sağlamak için gereklidir.

Azure dağıtımında SAP'niz için şirket içi bağlantı sağlamak için birçok seçeneğiniz vardır. Ağ dağıtımı genellikle merkez-uç ağ topolojisi veya merkez-uç topolojisinin bir uzantısıdır ve genel bir sanal WAN'dır.

Şirket içi SAP dağıtımları için Azure ExpressRoute üzerinden özel bir bağlantı kullanmanızı öneririz. Daha küçük SAP iş yükleri, uzak bölgeler veya daha küçük ofisler için VPN şirket içi bağlantısı kullanılabilir. ExpressRoute'u bir VPN siteden siteye bağlantıyla yük devretme yolu olarak kullanmak her iki hizmetin de olası bir bileşimidir.

Giden ve gelen İnternet bağlantısı

SAP ortamınız, işletim sistemi depo güncelleştirmelerini almak, genel uç noktalarındaki SAP SaaS uygulamalarına bağlantı kurmak veya genel uç noktası üzerinden bir Azure hizmetine erişmek için İnternet bağlantısı gerektirir. Benzer şekilde, İnternet kullanıcıları SAP ortamınız tarafından sağlanan hizmetlere erişirken istemcileriniz için SAP Fiori uygulamalarına erişim sağlamanız gerekebilir. SAP ağ mimariniz, İnternet'e giden yolu ve gelen istekleri planlamanızı gerektirir.

NSG kurallarını kullanarak, bilinen hizmetler için ağ hizmeti etiketlerini kullanarak ve güvenlik duvarınıza veya diğer ağ sanal gerecinize yönlendirme ve IP adresi oluşturarak sanal ağınızın güvenliğini sağlayın. Bu görevlerin veya önemli noktaların tümü mimarinin bir parçasıdır. Özel ağlardaki kaynakların ağ Katman 4 ve Katman 7 güvenlik duvarları tarafından korunması gerekir.

İnternet ile iletişim yolları, en iyi yöntemler mimarisinin odak noktasıdır.

SAP iş yükleri için Azure VM'leri

Bazı Azure VM aileleri özellikle SAP iş yükleri için, bazıları ise sap HANA iş yükü için uygundur. Doğru VM türünü ve SAP iş yükünüzü destekleme özelliğini bulmanın yolu, Azure dağıtımları için hangi SAP yazılımının desteklendiği bölümünde açıklanmıştır. Ayrıca SAP Note 1928533 , tüm sertifikalı Azure VM'lerini ve varsa SAP Uygulama Performansı Standardı (SAPS) karşılaştırması ve sınırlamalarıyla ölçülen performans özelliklerini listeler. SAP iş yükü için sertifikalı VM türleri, CPU ve bellek kaynakları için aşırı sağlama kullanmaz.

Yalnızca desteklenen VM türlerinin seçimine bakmanın ötesinde, bu VM türlerinin bölgeye göre kullanılabilir ürünler temelinde belirli bir bölgede kullanılabilir olup olmadığını denetlemeniz gerekir. En az önemli olan, bir VM için aşağıdaki özelliklerin senaryonuza uygun olup olmadığını belirlemektir:

  • CPU ve bellek kaynakları
  • Saniye başına giriş/çıkış işlemleri (IOPS) bant genişliği
  • Ağ özellikleri
  • Eklenebilen disk sayısı
  • Belirli Azure depolama türlerini kullanma olanağı

Belirli bir FM ailesi ve türüyle ilgili bu bilgileri almak için bkz . Azure'da sanal makinelerin boyutları.

Azure VM'leri için fiyatlandırma modelleri

VM fiyatlandırma modeli için kullanmayı tercih ettiğiniz seçeneği belirleyebilirsiniz:

  • Kullandıkça öde fiyatlandırma modeli
  • Bir yıllık ayrılmış veya tasarruf planı
  • Üç yıllık ayrılmış veya tasarruf planı
  • Spot fiyatlandırma modeli

Farklı Azure hizmetleri, işletim sistemleri ve bölgeleri için VM fiyatlandırması hakkında ayrıntılı bilgi edinmek için bkz . Sanal makine fiyatlandırması.

Bir yıllık ve üç yıllık tasarruf planlarının ve ayrılmış örneklerin fiyatlandırması ve esnekliği hakkında bilgi edinmek için şu makalelere bakın:

Spot fiyatlandırması hakkında daha fazla bilgi için bkz. Azure Spot Sanal Makineler.

Aynı VM türü için fiyatlandırma, Azure bölgeleri arasında farklılık gösterebilir. Bazı müşteriler daha ucuz bir Azure bölgesine dağıtımdan yararlandığından, bölgeye göre fiyatlandırma hakkında bilgiler planlarken yararlı olabilir.

Azure ayrıca ayrılmış bir konak kullanma seçeneği sunar. Ayrılmış bir ana bilgisayar kullanmak, Azure hizmetleri için düzeltme eki uygulama döngüleri hakkında daha fazla denetim sağlar. Kendi zamanlamanızı ve döngülerinizi desteklemek için düzeltme eki uygulama zamanlayabilirsiniz. Bu teklif, özellikle bir iş yükünün normal döngüsünü izlemeyen bir iş yüküne sahip olan müşterilere yöneliktir. Daha fazla bilgi için bkz . Azure ayrılmış konakları.

Sap iş yükü için Ayrılmış Azure konağı kullanılması desteklenir. Altyapı düzeltme eki uygulama ve bakım planları üzerinde daha fazla denetim sahibi olmak isteyen birçok SAP müşterisi Azure ayrılmış konaklarını kullanır. Microsoft'un VM'leri barındıran Azure altyapısını nasıl koruduğu ve yaması hakkında daha fazla bilgi için bkz . Azure'da sanal makineler için bakım.

VM'ler için işletim sistemi

Bir SAP sistemini yüklemek veya geçirmek üzere Azure'daki bir SAP ortamı için yeni VM'ler dağıttığınızda, iş yükünüz için doğru işlem sistemini seçmeniz önemlidir. Azure, Linux ve Windows için çok çeşitli işletim sistemi görüntüleri ve SAP sistemleri için birçok uygun seçenek sunar. Ayrıca şirket içi ortamınızdan özel görüntüler oluşturabilir veya karşıya yükleyebilir ya da görüntü galerilerini kullanabilir veya genelleştirebilirsiniz.

Kullanılabilir seçenekler hakkında ayrıntılar ve bilgiler için:

Gerekirse SAP iş yükünüz için bir işletim sistemi güncelleştirme altyapısını ve bağımlılıklarını planlayın. Güncelleştirme zaman döneminiz boyunca aynı düzeltme ekleri ve güncelleştirme sürümlerini kullanarak SAP ortamının tüm katmanlarını (korumalı alan, geliştirme, ön üretim ve üretim) eşitlenmiş durumda tutmak için bir depo hazırlama ortamı kullanmayı göz önünde bulundurun.

1. nesil ve 2. nesil VM'ler

Azure'da vm'yi 1. nesil veya 2. nesil olarak dağıtabilirsiniz. Azure'da 2. nesil VM'ler için destek, 2. nesil olarak dağıtabileceğiniz Azure VM ailelerini listeler. Makalede ayrıca Azure'daki 1. nesil ve 2. nesil VM'ler arasındaki işlevsel farklar da listelenmiştir.

Bir VM dağıttığınızda, seçtiğiniz işletim sistemi görüntüsü VM'nin 1. nesil mi yoksa 2. nesil bir VM mi olacağını belirler. SAP için Azure'da (Red Hat Enterprise Linux, SuSE Enterprise Linux ve Windows veya Oracle Enterprise Linux) kullanılabilen tüm işletim sistemi görüntülerinin en son sürümleri hem 1. nesil hem de 2. nesilde kullanılabilir. Doğru VM neslini dağıtmak için görüntü açıklamasına göre bir görüntüyü dikkatle seçmek önemlidir. Benzer şekilde, 1. nesil veya 2. nesil olarak özel işletim sistemi görüntüleri oluşturabilirsiniz ve bunlar VM dağıtım sırasında VM'nin neslini etkiler.

Dekont

VM boyutundan bağımsız olarak Azure'daki tüm SAP dağıtımlarınızda 2. nesil VM'leri kullanmanızı öneririz. SAP için en son Azure VM'lerinin tümü 2. nesildir veya yalnızca 2. nesille sınırlıdır. Bazı VM aileleri şu anda yalnızca 2. nesil VM'leri desteklemektedir. Yakında kullanıma sunulacak bazı VM aileleri yalnızca 2. nesli destekleyebilecektir.

Seçilen işletim sistemi görüntüsüne göre vm'nin 1. nesil mi yoksa yalnızca 2. nesil mi olduğunu belirleyebilirsiniz. Mevcut bir VM'yi bir nesilden diğerine değiştiremezsiniz.

Dağıtılan vm'yi 1. nesilden 2. nesile değiştirmek Azure'da mümkün değildir. VM neslini değiştirmek için, istediğiniz nesil olan yeni bir VM dağıtmanız ve yazılımınızı yeni nesil VM'ye yeniden yüklemeniz gerekir. Bu değişiklik yalnızca VM'nin temel VHD görüntüsünü etkiler ve veri diskleri ya da ekli Ağ Dosya Sistemi (NFS) ya da Sunucu İleti Bloğu (SMB) paylaşımlarını etkilemez. İlk olarak 1. nesil vm'ye atanan veri diskleri, NFS paylaşımları veya SMB paylaşımları yeni nesil 2 VM'ye eklenebilir.

Mv2 serisi gibi bazı VM aileleri yalnızca 2. nesli destekler. Gelecekte yeni VM aileleri için de aynı gereksinim geçerli olabilir. Bu senaryoda, mevcut 1. nesil vm yeni VM ailesi ile çalışacak şekilde yeniden boyutlandırılamaz. Azure platformunun 2. nesil gereksinimlerine ek olarak SAP bileşenlerinizin vm'nin nesliyle ilgili gereksinimleri de olabilir. Seçtiğiniz VM ailesinin 2. nesil gereksinimleri hakkında bilgi edinmek için bkz. SAP Not 1928533.

Azure VM'leri için performans sınırları

Genel bulut olarak Azure, altyapıyı müşteri tabanı genelinde güvenli bir şekilde paylaşmaya bağımlıdır. Ölçeklendirmeyi ve kapasiteyi etkinleştirmek için her kaynak ve hizmet için performans sınırları tanımlanır. Azure altyapısının işlem tarafında, her VM boyutu için tanımlanan sınırları göz önünde bulundurmak önemlidir.

Her VM'nin disk ve ağ aktarım hızı, eklenebilecek disk sayısı, kendi aktarım hızı ve IOPS sınırları olan yerel geçici depolama alanı, bellek boyutu ve kullanılabilir vCPU sayısı gibi farklı bir kotası vardır.

Dekont

Azure'da bir SAP çözümü için VM boyutu hakkında karar alırken, her VM boyutu için performans sınırlarını dikkate almanız gerekir. Belgelerde açıklanan kotalar, teorik maksimum ulaşılabilir değerleri temsil eder. Disk başına IOPS performans sınırı küçük giriş/çıkış (G/Ç) değerleriyle (örneğin, 8 KB) elde edilebilir, ancak büyük G/Ç değerleriyle (örneğin, 1 MB) elde edilemeyebilir.

VM'ler gibi, sap iş yükü ve diğer tüm Azure hizmetleri için her depolama türü için aynı performans sınırları vardır.

SAP dağıtımınızda kullanılacak VM'leri planlayıp seçtiğinizde şu faktörleri göz önünde bulundurun:

  • Bellek ve CPU gereksinimleriyle başlayın. CPU gücü için SAPS gereksinimlerini DBMS bölümüne ve SAP uygulama bölümlerine ayırın. Mevcut sistemler için, sık kullandığınız donanımla ilgili SAPS, mevcut SAP Standart Uygulama Karşılaştırmaları temelinde belirlenebilir veya tahmin edilebilir. Yeni dağıtılan SAP sistemleri için, sistemin SAPS gereksinimlerini belirlemek için bir boyutlandırma alıştırmasını tamamlayın.

  • Mevcut sistemler için DBMS sunucusundaki G/Ç aktarım hızı ve IOPS ölçülmelidir. Yeni sistemler için, yeni sistemin boyutlandırma alıştırması size DBMS tarafındaki G/Ç gereksinimleri hakkında genel bir fikir de vermelidir. Emin değilseniz, sonunda bir kavram kanıtı yürütmeniz gerekir.

  • DBMS sunucusu için SAPS gereksinimini, farklı Azure VM türlerinin sağlayabilecekleri SAPS ile karşılaştırın. Farklı Azure VM türlerinin SAPS'leri hakkındaki bilgiler SAP Not 1928533 belgelenmiştir. Veritabanı katmanı, çoğu dağıtımda ölçeği genişletilmeyen bir SAP NetWeaver sistemindeki katman olduğundan, odak önce DBMS VM'de olmalıdır. Buna karşılık SAP uygulama katmanının ölçeği genişletilebilir. Tek tek DBMS kılavuzları önerilen depolama yapılandırmalarını açıklar.

  • Bulgularınızı özetlemek için:

    • Kullanmayı beklediğiniz Azure VM sayısı.
    • Her SAP katmanı için tek tek VM ailesi ve VM SKU'ları: DBMS, (A)SCS ve uygulama sunucusu.
    • G/Ç aktarım hızı ölçüleri veya hesaplanan depolama kapasitesi gereksinimleri.

HANA Büyük Örnekler hizmeti

Azure, Azure Büyük Örneklerinde SAP HANA adlı ayrılmış bir teklifte büyük bir HANA veritabanının ölçeğini artırma veya ölçeği genişletme işlemleri için işlem özellikleri sunar. Bu teklif, Azure'da kullanılabilen VM'leri genişletir.

Dekont

HANA Büyük Örnekler hizmeti gün batımı modundadır ve yeni müşterileri kabul etmez. Mevcut HANA Büyük Örnekleri müşterileri için birim sağlama hala mümkündür.

Azure'da SAP için Depolama

Azure VM'leri kalıcılık için çeşitli depolama seçeneklerini kullanır. Basit bir ifadeyle, VM'ler kalıcı ve geçici veya kalıcı olmayan depolama türlerine ayrılabilir.

SAP iş yükleri ve belirli SAP bileşenleri için birden çok depolama seçeneği arasından seçim yapabilirsiniz. Daha fazla bilgi için bkz . SAP iş yükleri için Azure depolama. Makale, SAP'nin her bölümü için depolama mimarisini kapsar: işletim sistemi, uygulama ikili dosyaları, yapılandırma dosyaları, veritabanı verileri, günlük ve izleme dosyaları ve diskte depolanan veya dosya paylaşımlarında erişilen diğer uygulamalarla dosya arabirimleri.

VM'lerde geçici disk

SAP için Azure VM'lerinin çoğu yönetilen disk olmayan geçici bir disk sunar. Geçici diski yalnızca harcanabilir veriler için kullanın. Geçici disk üzerindeki veriler öngörülemeyen bakım olayları veya VM yeniden dağıtımı sırasında kaybolabilir. Geçici diskin performans özellikleri, bunları işletim sisteminin takas/sayfa dosyaları için ideal hale getirir.

Hiçbir uygulama veya uygun olmayan işletim sistemi verileri geçici bir diskte depolanmamalıdır. Windows ortamlarında geçici sürücüye genellikle D sürücüsü olarak erişilir. Linux sistemlerinde bağlama noktası genellikle /dev/sdb cihazı, /mnt veya /mnt/resource'tır.

Bazı VM'ler geçici sürücü sunmaz. SAP için bu VM boyutlarını kullanmayı planlıyorsanız işletim sistemi diskinin boyutunu artırmanız gerekebilir. Daha fazla bilgi için bkz. SAP Not 1928533. Geçici diski olan VM'ler için, Azure'daki sanal makineler için boyutlar bölümündeki her vm serisi için geçici disk boyutu ve IOPS ve aktarım hızı sınırları hakkında bilgi edinin.

Geçici diskleri olan bir VM serisi ile geçici diskleri olmayan bir VM serisi arasında doğrudan yeniden boyutlandıramazsınız. Şu anda, bu tür iki VM ailesi arasında yeniden boyutlandırma başarısız olur. Çözüm, işletim sistemi disk anlık görüntüsü kullanarak yeni boyutta geçici diski olmayan VM'yi yeniden oluşturmaktır. Diğer tüm veri disklerini ve ağ arabirimini koruyun. Yerel geçici diske sahip bir VM boyutunu, olmayan bir VM boyutuna yeniden boyutlandırmayı öğrenin.

SAP için ağ paylaşımları ve birimler

SAP sistemleri genellikle bir veya daha fazla ağ dosya paylaşımı gerektirir. Dosya paylaşımları genellikle aşağıdaki seçeneklerden biridir:

  • SAP aktarım dizini (/usr/sap/trans veya TRANSDIR).
  • Birden çok uygulama sunucusu dağıtmak için SAP birimleri veya paylaşılan sapmnt veya saploc birimleri.
  • SAP (A)SCS, SAP ERS veya veritabanı (/hana/shared) için yüksek kullanılabilirlik mimarisi birimleri.
  • Dosya içeri ve dışarı aktarma için üçüncü taraf uygulamaları çalıştıran dosya arabirimleri.

Bu senaryolarda, Azure Dosyalar veya Azure NetApp Files gibi bir Azure hizmeti kullanmanızı öneririz. Bu hizmetler seçtiğiniz bölgelerde yoksa veya çözüm mimariniz için kullanılamıyorsa, alternatifler kendi kendine yönetilen, VM tabanlı uygulamalardan veya üçüncü taraf hizmetlerden NFS veya SMB dosya paylaşımları sağlamaktır. Azure'da bir SAP sisteminde depolama katmanları için üçüncü taraf hizmetleri kullanıyorsanız SAP desteğine yönelik sınırlamalar hakkında sap not 2015553 bakın.

Ağ paylaşımlarının genellikle kritik doğası gereği ve genellikle bir tasarımda (yüksek kullanılabilirlik için) veya işlemde (dosya arabirimi için) tek bir hata noktası olduğundan, her Azure yerel hizmetine kendi kullanılabilirliği, SLA'sı ve dayanıklılığı için güvenmenizi öneririz. Planlama aşamasında şu faktörleri göz önünde bulundurmak önemlidir:

  • SAP sistem kimliği (SID), yatay ve bölge başına kullanılacak paylaşımlar dahil olmak üzere NFS veya SMB paylaşım tasarımı.
  • Azure NetApp Files gibi hizmetler için özel uç noktalar veya ayrılmış alt ağlar için IP gereksinimi dahil olmak üzere alt ağ boyutlandırma.
  • SAP sistemlerine ve bağlı uygulamalara ağ yönlendirme.
  • Azure Dosyalar için genel veya özel uç nokta kullanımı.

Gereksinimler ve yüksek kullanılabilirlik senaryosunda NFS veya SMB paylaşımı kullanma hakkında bilgi için bkz . Yüksek kullanılabilirlik.

Dekont

Ağ paylaşımlarınız için Azure Dosyalar kullanıyorsanız, özel uç nokta kullanmanızı öneririz. Olası bir bölgesel hata durumunda, NFS istemciniz otomatik olarak iyi durumdaki bir bölgeye yönlendirilir. VM'lerinizde NFS veya SMB paylaşımlarını yeniden bağlamanız gerekmez.

SAP ortamınız için güvenlik

Azure'da SAP iş yükünüzü korumak için güvenliğin birden çok yönünü planlamanız gerekir:

  • Ağ segmentasyonu ve her alt ağın ve ağ arabiriminin güvenliği.
  • SAP yatay içindeki her katmanda şifreleme.
  • Son kullanıcı ve yönetim erişimi ve çoklu oturum açma hizmetleri için kimlik çözümü.
  • Tehdit ve işlem izleme.

Bu bölümdeki konular tüm kullanılabilir hizmetlerin, seçeneklerin ve alternatiflerin kapsamlı bir listesi değildir. Azure'daki tüm SAP dağıtımları için dikkate alınması gereken birkaç en iyi yöntem listelemektedir. Kurumsal gereksinimlerinize veya iş yükü gereksinimlerinize bağlı olarak ele alınacak başka yönler de vardır. Güvenlik tasarımı hakkında daha fazla bilgi için genel Azure kılavuzu için aşağıdaki kaynaklara bakın:

Güvenlik gruplarını kullanarak sanal ağların güvenliğini sağlama

Azure'da SAP ortamınızı planlamak, yalnızca SAP iş yüklerine ayrılmış sanal ağlar ve alt ağlar ile bir miktar ağ segmentasyonu içermelidir. Alt ağ tanımı için en iyi yöntemler Ağ ve diğer Azure mimarisi kılavuzlarında açıklanmıştır. Gelen ve giden bağlantıya izin vermek için NSG'leri NSG'ler içinde ASG'lerlekullanmanızı öneririz. ASG'leri tasarlarken, bir VM'deki her NIC birden çok ASG ile ilişkilendirilebilir, böylece farklı gruplar oluşturabilirsiniz. Örneğin, DBMS VM'leri için, ortamınızdaki tüm veritabanı sunucularını içeren bir ASG oluşturun. Tek bir SAP SID'nin tüm VM'leri (uygulama ve DBMS) için başka bir ASG oluşturun. Bu şekilde, genel veritabanı ASG'si için bir NSG kuralı ve yalnızca SID'ye özgü ASG için başka bir daha özel kural tanımlayabilirsiniz.

NSG'ler performansı NSG için tanımladığınız kurallarla kısıtlamaz. Trafik akışını izlemek için, isteğe bağlı olarak NSG akış günlüğünü şüpheli ağ etkinliğini izlemek ve üzerinde işlem yapmak için tercih ettiğiniz bir bilgi olay yönetimi (SIEM) veya yetkisiz erişim algılama sistemi (IDS) tarafından değerlendirilen günlüklerle etkinleştirebilirsiniz.

Bahşiş

NSG'leri yalnızca alt ağ düzeyinde etkinleştirin. NSG'ler hem alt ağ düzeyinde hem de NIC düzeyinde etkinleştirilse de, her ikisinde de etkinleştirme, ağ trafiği kısıtlamalarını analiz ederken sorun giderme durumlarında genellikle bir engeldir. NSG'leri yalnızca istisnai durumlarda ve gerektiğinde NIC düzeyinde kullanın.

Hizmetler için özel uç noktalar

Birçok Azure PaaS hizmetine varsayılan olarak genel uç nokta üzerinden erişilir. İletişim uç noktası Azure arka uç ağında bulunsa da uç nokta genel İnternet'te kullanıma sunulur. Özel uç noktalar , kendi özel sanal ağınızdaki bir ağ arabirimidir. özel uç nokta, Azure Özel Bağlantı aracılığıyla hizmeti sanal ağınıza projeler. Seçili PaaS hizmetlerine daha sonra ağınızdaki IP üzerinden özel olarak erişilir. Yapılandırmaya bağlı olarak, hizmet büyük olasılıkla yalnızca özel uç nokta üzerinden iletişim kuracak şekilde ayarlanabilir.

Özel uç nokta kullanmak veri sızıntısına karşı korumayı artırır ve genellikle şirket içi ve eşlenmiş ağlardan erişimi basitleştirir. Çoğu durumda, genellikle genel uç noktalar için gereken güvenlik duvarı bağlantı noktalarını açma ağ yönlendirmesi ve işlemi basitleştirilir. Kaynaklara özel bir uç nokta tarafından erişildiği için ağınızda zaten var.

Özel uç nokta kullanma seçeneği sunan Azure hizmetlerini öğrenmek için bkz. Özel Bağlantı kullanılabilir hizmetler. NFS veya Azure Dosyalar olan SMB için SAP iş yükleri için her zaman özel uç noktaları kullanmanızı öneririz. Hizmeti kullanarak tahakkuk eden ücretler hakkında bilgi edinmek için bkz . Özel uç nokta fiyatlandırması. Bazı Azure hizmetleri isteğe bağlı olarak hizmete maliyeti de içerebilir. Bu bilgiler bir hizmetin fiyatlandırma bilgilerine dahildir.

Şifreleme

Şirket ilkelerinize bağlı olarak, SAP iş yükleriniz için Azure'daki varsayılan seçeneklerin ötesinde şifreleme gerekebilir.

Altyapı kaynakları için şifreleme

Azure'da yönetilen diskler ve blob depolama varsayılan olarak platform tarafından yönetilen anahtar (PMK) ile şifrelenir. Ayrıca yönetilen diskler için kendi anahtarını getir (BYOK) şifrelemesi ve Azure'daki SAP iş yükleri için blob depolama desteklenir. Yönetilen disk şifrelemesi için, kurumsal güvenlik gereksinimlerinize bağlı olarak farklı seçenekler arasından seçim yapabilirsiniz. Azure şifreleme seçenekleri şunlardır:

  • Depolama tarafı şifreleme (SSE) PMK (SSE-PMK)
  • SSE müşteri tarafından yönetilen anahtar (SSE-CMK)
  • Beklemedeki verilerde çift şifreleme
  • Konak tabanlı şifreleme

Azure Disk Şifrelemesi açıklaması da dahil olmak üzere daha fazla bilgi için bkz. Azure şifreleme seçeneklerinin karşılaştırması.

Dekont

Şu anda, olası bir performans sınırlaması nedeniyle Linux ile çalışırken M serisi VM ailesindeki bir VM'de konak tabanlı şifreleme kullanmayın. Yönetilen diskler için SSE-CMK şifrelemesi kullanımı bu sınırlamadan etkilenmez.

Linux sistemlerinde sap dağıtımları için Azure Disk Şifrelemesi kullanmayın. Azure Disk Şifrelemesi, Azure Key Vault'tan CMK'leri kullanarak SAP VM'lerinin içinde çalışan şifrelemeyi gerektirir. Linux için Azure Disk Şifrelemesi SAP iş yükleri için kullanılan işletim sistemi görüntülerini desteklemez. Azure Disk Şifrelemesi SAP iş yüklerine sahip Windows sistemlerinde kullanılabilir, ancak Azure Disk Şifrelemesi veritabanında yerel şifreleme ile birleştiremez. Azure Disk Şifrelemesi yerine veritabanı yerel şifrelemesi kullanmanızı öneririz. Daha fazla bilgi edinmek için sonraki bölüme bakın.

Yönetilen disk şifrelemesine benzer şekilde, bekleyen Azure Dosyalar şifreleme (SMB ve NFS) PMK'ler veya CMK'ler ile kullanılabilir.

SMB ağ paylaşımları için, yapılandırma aktarım içi şifreleme desteğini etkilediğinden SMB sürümleriyle Azure Dosyalar ve işletim sistemi bağımlılıklarını dikkatle gözden geçirin.

Önemli

Müşteri tarafından yönetilen şifreleme kullanıyorsanız şifreleme anahtarlarını depolamak ve korumak için dikkatli bir planın önemi fazla abartılamaz. Şifreleme anahtarları olmadan, diskler gibi şifrelenmiş kaynaklara erişilemez ve veri kaybına yol açabilir. Anahtarları korumayı ve anahtarlara yalnızca ayrıcalıklı kullanıcılara veya hizmetlere erişimi dikkatle göz önünde bulundurun.

SAP bileşenleri için şifreleme

SAP düzeyinde şifreleme iki katmana ayrılabilir:

  • DBMS şifrelemesi
  • Aktarım şifrelemesi

DBMS şifrelemesi için, SAP NetWeaver veya SAP S/4HANA dağıtımı için desteklenen her veritabanı yerel şifrelemeyi destekler. Saydam veritabanı şifrelemesi, Azure'da bulunan tüm altyapı şifrelemelerinden tamamen bağımsızdır. SSE ve veritabanı şifrelemesini aynı anda kullanabilirsiniz. Şifreleme kullandığınızda, şifreleme anahtarlarının konumu, depolaması ve güvenliği kritik önem taşır. Veritabanınızı başlatamayacağınız veya kurtaramayacağınız için herhangi bir şifreleme anahtarı kaybı veri kaybına neden olur.

Bazı veritabanlarının veritabanı şifreleme yöntemi olmayabilir veya etkinleştirmek için ayrılmış bir ayar gerektirmeyebilir. Diğer veritabanları için veritabanı şifrelemesi etkinleştirildiğinde DBMS yedeklemeleri örtük olarak şifrelenebilir. Saydam veritabanı şifrelemesini etkinleştirmeyi ve kullanmayı öğrenmek için aşağıdaki SAP belgelerine bakın:

Yazılım şifrelemesini etkinleştirme, kullanma veya sorun giderme konusunda destek için SAP'ye veya DBMS satıcınıza başvurun.

Önemli

Şifreleme anahtarlarınızı depolamak ve korumak için dikkatli bir plana sahip olmak ne kadar önemli olduğu abartılamaz. Şifreleme anahtarları olmadan veritabanı veya SAP yazılımına erişilemez olabilir ve verileri kaybedebilirsiniz. Anahtarların nasıl korunacaklarını dikkatlice göz önünde bulundurun. Anahtarlara yalnızca ayrıcalıklı kullanıcılar veya hizmetler tarafından erişim izni verin.

SAP altyapıları ile DBMS arasındaki SQL Server bağlantılarına aktarım veya iletişim şifrelemesi uygulanabilir. Benzer şekilde, SAP sunu katmanından (SAPGui güvenli ağ bağlantısı veya SNC) ya da web ön ucuna bir HTTPS bağlantısından bağlantıları şifreleyebilirsiniz. Aktarım sırasında şifrelemeyi etkinleştirmek ve yönetmek için uygulama satıcısının belgelerine bakın.

Tehdit izleme ve uyarı

Tehdit izleme ve uyarı çözümlerini dağıtmak ve kullanmak için kuruluşunuzun mimarisini kullanarak başlayın. Azure hizmetleri, tehdit koruması ve genel SAP dağıtım planınıza ekleyebileceğiniz bir güvenlik görünümü sağlar. Bulut için Microsoft Defender tehdit koruması gereksinimini giderir. Bulut için Defender genellikle yalnızca SAP bileşenleri için değil, azure dağıtımının tamamı için genel idare modelinin bir parçasıdır.

Güvenlik bilgileri olay yönetimi (SIEM) ve güvenlik düzenleme otomatik yanıt (SOAR) çözümleri hakkında daha fazla bilgi için bkz . SAP tümleştirmesi için Microsoft Sentinel çözümleri.

SAP VM'leri içindeki güvenlik yazılımı

Linux için SAP Not 2808515 ve Windows için SAP Not 106267 , SAP sunucularında virüs tarayıcıları veya güvenlik yazılımı kullanırken gereksinimleri ve en iyi yöntemleri açıklar. Azure'da SAP bileşenlerini dağıtırken SAP önerilerini izlemenizi öneririz.

Yüksek kullanılabilirlik

Azure'da SAP yüksek kullanılabilirliğinin iki bileşeni vardır:

  • Azure altyapısı yüksek kullanılabilirliği: Azure işlem (VM' ler), ağ ve depolama hizmetlerinin yüksek kullanılabilirliği ve SAP uygulaması kullanılabilirliğini nasıl artırabilecekleri.

  • SAP uygulaması yüksek kullanılabilirliği: Hizmet düzeltmesi kullanılarak Azure altyapısı yüksek kullanılabilirliği ile nasıl birleştirilebilir? SAP yazılım bileşenlerinde yüksek kullanılabilirlik kullanan bir örnek:

    • SAP (A)SCS ve SAP ERS örneği
    • Veritabanı sunucusu

Azure'da SAP için yüksek kullanılabilirlik hakkında daha fazla bilgi için aşağıdaki makalelere bakın:

Linux üzerinde Pacemaker ve Windows Server yük devretme kümelemesi, Azure üzerinde Microsoft tarafından doğrudan desteklenen SAP iş yükleri için tek yüksek kullanılabilirlik çerçeveleridir. Diğer yüksek kullanılabilirlik çerçeveleri Microsoft tarafından desteklenmez ve satıcının tasarım, uygulama ayrıntıları ve operasyon desteğine ihtiyacı vardır. Daha fazla bilgi için bkz . Azure'da SAP için desteklenen senaryolar.

Olağanüstü durum kurtarma

SAP uygulamaları genellikle bir kuruluştaki iş açısından en kritik süreçler arasındadır. Önem derecelerine ve öngörülemeyen bir kesintiden sonra tekrar faaliyete geçmek için gereken süreye bağlı olarak, iş sürekliliği ve olağanüstü durum kurtarma (BCDR) senaryoları dikkatle planlanmalıdır.

Bu gereksinimi nasıl karşılayacağınızı öğrenmek için bkz . SAP iş yükü için olağanüstü durum kurtarmaya genel bakış ve altyapı yönergeleri.

Backup

BCDR stratejinizin bir parçası olarak SAP iş yükünüz için yedekleme, planlanan tüm dağıtımların ayrılmaz bir parçası olmalıdır. Yedekleme çözümü bir SAP çözüm yığınının tüm katmanlarını kapsamalıdır: VM, işletim sistemi, SAP uygulama katmanı, DBMS katmanı ve herhangi bir paylaşılan depolama çözümü. SAP iş yükünüz tarafından kullanılan Azure hizmetleri ve şifreleme ve erişim anahtarları gibi diğer önemli kaynaklar için yedeklemenin de yedekleme ve BCDR tasarımınızın bir parçası olması gerekir.

Azure Backup yedekleme için PaaS çözümleri sunar:

  • VM için Azure Backup aracılığıyla VM yapılandırması, işletim sistemi ve SAP uygulama katmanı (yönetilen disklerde veri yeniden boyutlandırma). Mimarinizin bu çözümü kullanabileceğini doğrulamak için destek matrisini gözden geçirin.
  • SQL Server ve SAP HANA veritabanı verileri ve günlük yedekleme. HANA sistem çoğaltması veya SQL Always On gibi veritabanı çoğaltma teknolojileri için destek ve eşleştirilmiş bölgeler için bölgeler arası destek içerir.
  • Azure Dosyalar aracılığıyla dosya paylaşımı yedeklemesi. NFS veya SMB desteğini ve diğer yapılandırma ayrıntılarını doğrulayın.

Alternatif olarak, Azure NetApp Files'ı dağıtırsanız, SAP HANA ve Oracle DBMS ile zamanlanmış yedekleme tümleştirmesi gibi yedekleme seçenekleri birim düzeyinde kullanılabilir.

Azure Backup çözümleri, kötü amaçlı veya yanlışlıkla silmeyi ve veri kaybını önlemeye yönelik geçici silme seçeneği sunar. Geçici silme, Azure Dosyalar kullanarak dağıttığınız dosya paylaşımları için de kullanılabilir.

Kendi oluşturduğunuz ve yönettiğiniz bir çözüm için veya üçüncü taraf yazılım kullanıyorsanız yedekleme seçenekleri kullanılabilir. Bir seçenek, blob verileri için sabit depolamayı kullanmak da dahil olmak üzere hizmetleri Azure Depolama ile kullanmaktır. Şu anda bu kendi kendine yönetilen seçenek, SAP ASE veya IBM Db2 gibi bazı veritabanları için DBMS yedekleme seçeneği olarak gerekli olacaktır.

Fidye yazılımı saldırılarına karşı koruma ve doğrulama için Azure'daki en iyi yöntemlerdeki önerileri kullanın.

Bahşiş

Yedekleme stratejinizin dağıtım otomasyonunuzu korumayı, Azure kaynakları için şifreleme anahtarlarını ve kullanıldıysa saydam veritabanı şifrelemesini içerdiğini emin olun.

Bölgeler arası yedekleme

Bölgeler arası yedekleme gereksinimleri için çözüm tarafından sunulan Kurtarma Süresi Hedefi (RTO) ve Kurtarma Noktası Hedefi'ni (RPO) ve BCDR tasarımınızla ve gereksinimlerinizle eşleşip eşleşmediğini belirleyin.

Azure'a SAP geçişi

Çok çeşitli SAP ürünleri, sürüm bağımlılıkları ve kullanılabilir yerel işletim sistemi ve DBMS teknolojileri için tüm geçiş yaklaşımlarını ve seçeneklerini açıklamak mümkün değildir. Kuruluşunuz için proje ekibi ve hizmet sağlayıcı tarafınızdaki temsilciler, Azure'a sorunsuz bir SAP geçişi için çeşitli teknikleri dikkate almalıdır.

  • Geçiş sırasında performansı test edin. SAP geçiş planlamasının önemli bir parçası teknik performans testidir. Geçiş ekibinin, anahtar personelin, bağlı arabirimler ve uygulamalar da dahil olmak üzere geçirilen SAP sisteminin uygulama ve teknik testlerini çalıştırması için yeterli süre ve kullanılabilirliğe izin vermelidir. Başarılı bir SAP geçişi için, bir test ortamındaki önemli iş süreçlerinin geçiş öncesi ve geçiş sonrası çalışma zamanı ile doğruluğunu karşılaştırmak kritik önem taşır. Üretim ortamını geçirmeden önce işlemleri iyileştirmek için bu bilgileri kullanın.

  • SAP geçişi için Azure hizmetlerini kullanın. Bazı VM tabanlı iş yükleri, Azure Geçişi veya Azure Site Recovery gibi hizmetler ya da üçüncü taraf bir araç kullanılarak Azure'a değiştirilmeden geçirilir. İşletim sistemi sürümünün ve çalıştırdığı SAP iş yükünün hizmet tarafından desteklendiğini dikkatle onaylayın.

    Çoğu zaman, bir hizmet veritabanı tutarlılığını garanti etmediğinden herhangi bir veritabanı iş yükü kasıtlı olarak desteklenmez. DBMS türü geçiş hizmeti tarafından destekleniyorsa, veritabanı değişikliği veya değişim sıklığı genellikle çok yüksektir. Çoğu meşgul SAP sistemi, geçiş araçlarının izin vermekte olduğu değişiklik oranını karşılamaz. Üretim geçişi yapılana kadar sorunlar görülmeyebilir veya bulunamayabilir. Çoğu durumda bazı Azure hizmetleri SAP sistemlerini geçirmek için uygun değildir. Azure Site Recovery ve Azure Geçişi'nin büyük ölçekli SAP geçişi için doğrulaması yoktur. Kanıtlanmış bir SAP geçiş metodolojisi, DBMS çoğaltma veya SAP geçiş araçlarına güvenmektir.

    Azure'da temel VM geçişi yerine dağıtım yapmak, şirket içi geçişten daha kolay ve tercih edilir. SAP çözümleri için Azure Center ve Azure dağıtım otomasyonu çerçevesi gibi otomatik dağıtım çerçeveleri otomatik görevlerin hızlı yürütülmesine olanak sağlar. HANA sistem çoğaltması, DBMS yedekleme ve geri yükleme veya SAP geçiş araçları gibi DBMS yerel çoğaltma teknolojilerini kullanarak SAP ortamınızı dağıtılan yeni bir altyapıya geçirmek için SAP sisteminiz hakkında yerleşik teknik bilgi kullanır.

  • Altyapı ölçeğini artırma. SAP geçişi sırasında daha fazla altyapı kapasitesine sahip olmak daha hızlı dağıtmanıza yardımcı olabilir. Proje ekibi, daha fazla CPU ve bellek sağlamak için VM boyutunu artırmayı düşünmelidir. Ekip ayrıca VM toplama depolama ve ağ aktarım hızını ölçeklendirmeyi de göz önünde bulundurmalıdır. Benzer şekilde, VM düzeyinde, premium SSD v1 için isteğe bağlı ani artış ve performans katmanlarıyla aktarım hızını artırmak için tek tek diskler gibi depolama öğelerini göz önünde bulundurun. Premium SSD v2'yi yapılandırılan değerlerin üzerinde kullanıyorsanız IOPS ve aktarım hızı değerlerini artırın. Performans sınırlarını artırmak için NFS ve SMB dosya paylaşımlarını büyütün. Azure tarafından yönetilen disklerin boyutunun azaltılmayabileceğini ve boyut, performans katmanları ve aktarım hızı KPI'lerindeki azalmanın çeşitli bekleme sürelerine sahip olabileceğini unutmayın.

  • Ağ ve veri kopyalamayı iyileştirme. SAP sisteminin Azure'a geçirilmesi her zaman büyük miktarda veri taşımayı içerir. Veriler veritabanı ve dosya yedeklemeleri veya çoğaltma, uygulamadan uygulamaya veri aktarımı veya SAP geçişi dışarı aktarma olabilir. Kullandığınız geçiş işlemine bağlı olarak, verileri taşımak için doğru ağ yolunu seçmeniz gerekir. Birçok veri taşıma işlemi için, verileri Azure depolamaya güvenli bir şekilde kopyalamanın en hızlı yolu özel ağ yerine İnternet'i kullanmaktır.

    ExpressRoute veya VPN kullanmak performans sorunlarına yol açabilir:

    • Geçiş verileri çok fazla bant genişliği kullanır ve Azure'da çalışan iş yüklerine kullanıcı erişimini engeller.
    • Güvenlik duvarı veya aktarım hızı sınırlama gibi şirket içi ağ performans sorunları genellikle yalnızca geçiş sırasında bulunur.

    Kullanılan ağ bağlantısından bağımsız olarak, veri taşıma işlemi için tek akışlı ağ performansı genellikle düşük olur. Birden çok TCP akışına göre veri aktarım hızını artırmak için birden çok akışı destekleyebilecek araçları kullanın. SAP belgelerinde ve bu konudaki birçok blog gönderisinde açıklanan iyileştirme tekniklerini uygulayın.

Bahşiş

Planlama aşamasında, Azure'a büyük veri aktarımları için kullanacağınız ayrılmış geçiş ağlarını göz önünde bulundurmanız önemlidir. Örnek olarak yedeklemeler veya veritabanı çoğaltması ya da Azure depolamaya veri aktarımları için genel uç nokta kullanma verilebilir. Geçişin kullanıcılarınız ve uygulamalarınız için ağ yolları üzerindeki etkisi beklenmelidir ve azaltılmalıdır. Ağ planlamanızın bir parçası olarak, geçişin tüm aşamalarını ve geçiş sırasında Azure'da kısmen üretken bir iş yükünün maliyetini göz önünde bulundurun.

SAP için destek ve işlemler

Azure'da SAP dağıtımı öncesinde ve sırasında dikkate alınması gereken diğer birkaç alan önemlidir.

SAP için Azure VM uzantısı

SAP için Azure İzleme Uzantısı, Gelişmiş İzleme ve Azure Uzantısı, SAP konak aracısına Azure altyapısı hakkında bazı temel veriler sağlamak için dağıtmanız gereken bir VM uzantısına başvurur. SAP notları uzantıyı İzleme Uzantısı veya Gelişmiş izleme olarak adlandırabilir. Azure'da buna SAP için Azure Uzantısı adı verilir. Destek amacıyla uzantının sap iş yükü çalıştıran tüm Azure VM'lerine yüklenmesi gerekir. Daha fazla bilgi edinmek için bkz . SAP için Azure VM uzantısı.

SAP desteği için SAProuter

Azure'da SAP ortamı çalıştırmak için destek amacıyla SAP'ye ve SAP'den bağlantı gerekir. Genellikle, İnternet üzerinden bir şifreleme ağ kanalı üzerinden veya SAP'ye özel bir VPN bağlantısı üzerinden bağlantı SAProuter bağlantısı biçimindedir. En iyi yöntemler ve Azure'da SAProuter'ın örnek bir uygulaması için Azure'da SAP için gelen ve giden İnternet bağlantıları'ndaki mimari senaryonuza bakın.

Sonraki adımlar