SAP NetWeaver için Azure sanal makineleri planlama ve uygulama

Microsoft Azure, şirketlerin işlem ve depolama kaynaklarını uzun tedarik döngüleri olmadan en az sürede almasına olanak sağlar. Azure sanal makine hizmeti, şirketlerin SAP NetWeaver tabanlı uygulamalar gibi klasik uygulamaları Azure 'a dağıtmasını ve şirket içinde kullanılabilir kaynak olmadan güvenilirliğini ve kullanılabilirliğini genişletmelerini sağlar. Azure sanal makine Hizmetleri, şirketlerin Azure sanal makinelerini şirket içi etki alanları, özel bulutları ve SAP sistem Yatağuna etkin bir şekilde tümleştirmelerini sağlayan şirketler arası bağlantıyı da destekler. bu teknik inceleme, Microsoft Azure sanal makinenin temellerini açıklar ve azure 'da sap NetWeaver yüklemeleri için planlama ve uygulama konuları ve azure üzerinde sap NetWeaver 'ın gerçek dağıtımlarını başlatmadan önce okunacak belge olması gerekir. Kağıda, belirtilen platformlarda SAP yazılımının yüklemeleri ve dağıtımları için birincil kaynakları temsil eden SAP yükleme belgeleri ve SAP notları da bu şekilde tamamlar.

Not

Bu makale Azure Az PowerShell modülünü kullanacak şekilde güncelleştirilmiştir. Az PowerShell modülü, Azure ile etkileşim kurmak için önerilen PowerShell modülüdür. Az PowerShell modülünü kullanmaya başlamak için Azure PowerShell’i yükleyin. Az PowerShell modülüne nasıl geçeceğinizi öğrenmek için bkz. Azure PowerShell’i AzureRM’den Az’ye geçirme.

Özet

Bulut bilgi Işlem, küçük şirketlerin büyük ve çok uluslu şirketlere kadar çok daha fazla ve BT sektörü dahilinde daha fazla önem elde eden yaygın olarak kullanılan bir terimdir.

Microsoft Azure, Microsoft 'un sunduğu, geniş bir yeni olanaklar sunan Cloud Services platformudur. Artık müşteriler, uygulamaları bulutta bir hizmet olarak hızlı bir şekilde temin edebilir ve serbest verebilir, böylece teknik veya bütçeleme kısıtlamalarıyla sınırlı değildir. Şirketler, donanım altyapısına zaman ve bütçe harcamak yerine uygulama, iş süreçlerine ve müşterilere ve kullanıcılara yönelik avantajlara odaklanabilirler.

Microsoft, Microsoft Azure Sanal Makine Hizmetleri ile kapsamlı bir Hizmet Olarak Altyapı (IaaS) platformu sunmaktadır. SAP NetWeaver tabanlı uygulamalar, Azure Sanal Makinelerinde (IaaS) desteklenmektedir. bu teknik inceleme, Microsoft Azure içinde SAP NetWeaver tabanlı uygulamaların seçim platformu olarak nasıl planlanıp uygulanacağını açıklar.

Kağıdın kendisi iki ana yönüyle odaklanır:

  • İlk bölümde, Azure 'da SAP NetWeaver tabanlı uygulamalar için desteklenen iki dağıtım modeli açıklanmaktadır. Ayrıca, Azure 'un SAP dağıtımlarını göz önünde bulundurarak genel işleme de açıklanmaktadır.
  • İkinci bölüm, ilk bölümünde açıklanan farklı senaryoları uygulayan ayrıntılar.

Ek kaynaklar için, bu belgedeki bölüm kaynakları bölümüne bakın.

Ön tanım tanımları

Belge boyunca aşağıdaki terimleri kullanırız:

  • IaaS: hizmet olarak altyapı
  • PaaS: hizmet olarak platform
  • SaaS: hizmet olarak yazılım
  • SAP bileşeni: ECC, siyah beyaz, çözüm Yöneticisi veya S/4HANA gibi tek bir SAP uygulaması. SAP bileşenleri geleneksel ABAP veya Java teknolojilerine veya Iş nesneleri gibi NetWeaver tabanlı olmayan bir uygulamaya dayalı olabilir.
  • SAP Ortamı: geliştirme, QAS, eğitim, DR veya üretim gibi bir iş işlevi gerçekleştirmek üzere mantıksal olarak gruplandırılan bir veya daha fazla SAP bileşeni.
  • SAP yatay: Bu terim, bir müşterinin BT yatay içindeki tüm SAP varlıklarını ifade eder. SAP yatay, tüm üretim ve üretim dışı ortamları içerir.
  • SAP System: Örneğin, bir SAP ERP geliştirme sistemi, SAP BW test sistemi, SAP CRM üretim sistemi vb. için DBMS katmanının ve uygulama katmanının birleşimi. Azure dağıtımlarında, bu iki katmanın şirket içi ve Azure arasında bölmek desteklenmez. SAP sisteminin şirket içinde dağıtıldığı ya da Azure 'da dağıtıldığı anlamına gelir. Ancak, SAP 'nin farklı sistemlerini Azure 'da veya şirket içinde dağıtabilirsiniz. Örneğin, Azure 'da SAP CRM geliştirme ve test sistemlerini, şirket içi SAP CRM üretim sistemine dağıtabilirsiniz.
  • Şirket içi veya hibrit: şirket içi veri merkezleri ve Azure arasında siteden siteye, çok siteli veya ExpressRoute bağlantısına sahip olan bir Azure aboneliğine sanal makinelerin dağıtıldığı bir senaryoyu açıklar. Yaygın Azure belgelerinde, bu tür dağıtımlar şirket içi veya hibrit senaryolar olarak da açıklanmaktadır. Bağlantının nedeni şirket içi etki alanlarını, şirket içi Active Directory/OpenLDAP ve şirket içi DNS 'yi Azure 'a genişletmenin nedenidir. Şirket içi yatay, aboneliğin Azure varlıklarına genişletilir. Bu uzantıya sahip olan VM 'Ler, şirket içi etki alanının bir parçası olabilir. Şirket içi etki alanının etki alanı kullanıcıları sunuculara erişebilir ve bu VM 'lerde (DBMS hizmetleri gibi) Hizmetleri çalıştırabilir. Şirket içinde dağıtılan ve Azure tarafından dağıtılan VM 'Ler arasındaki iletişim ve ad çözümlemesi mümkündür. Bu, SAP varlıklarını Azure 'a dağıtmanın en yaygın ve neredeyse dışlamalı durumdur. Daha fazla bilgi için bu makaleye ve Bumakaleye bakın.
  • Azure Izleme uzantısı, gelişmiş Izleme ve SAP için Azure uzantısı: bir ve aynı öğeyi tanıtın. SAP konak aracısına Azure altyapısı hakkında bazı temel veriler sağlamak için, sizin tarafınızdan dağıtılması gereken bir VM uzantısını açıklar. SAP 'de SAP notları, Izleme uzantısı veya Gelişmiş izleme olarak bu şekilde ifade edebilir. Azure 'da SAP Için Azure uzantısı olarak buna başvuruyoruz.

Not

SAP sistemleri çalıştıran Azure sanal makinelerinin, şirket içi bir etki alanının üyesi olduğu SAP sistemlerinin şirket içi veya karma dağıtımları, üretim SAP sistemlerinde desteklenir. Şirket içi veya karma Yapılandırma parçaları dağıtmak veya Azure 'a tam SAP landscapes desteği için desteklenir. Azure 'da tam SAP 'nin tamamen çalıştırılması, bu VM 'Lerin şirket içi etki alanı ve ADS/OpenLDAP kapsamında olmasını gerektirir.

Kaynaklar

Azure 'da SAP iş yüküne yönelik giriş noktası, Azure VM 'LERDE SAP kullanmaya başlamayolunda bulunur. Bu giriş noktasıyla başlayarak, şu konuları kapsayan birçok makaleyi bulabilirsiniz:

  • Azure 'da SAP NetWeaver ve Business One
  • Azure 'da çeşitli DBMS sistemleri için SAP DBMS Kılavuzu
  • Azure 'da SAP iş yükü için yüksek kullanılabilirlik ve olağanüstü durum kurtarma
  • Azure 'da SAP HANA çalıştırmak için özel kılavuz
  • SAP HANA DBMS için Azure HANA büyük örneklerine özgü rehberlik

Önemli

Başvurulan SAP yükleme kılavuzlarından veya diğer SAP belgelerinin bir bağlantısı kullanıldığında (başvuru ınstguide-01, bkz http://service.sap.com/instguides .). önkoşul, yükleme işlemi veya belirli sap işlevselliğinin ayrıntılarına geldiğinde, Microsoft belgeleri yalnızca Microsoft Azure bir sanal makinede yüklü ve çalıştırılan sap yazılımının belirli görevlerini kapsadığından, sap belgelerinin ve kılavuzların her zaman dikkatle okunmalıdır.

Aşağıdaki SAP notları, Azure 'daki SAP konusuyla ilgilidir:

Dekont numarası Başlık
1928533 Azure 'da SAP uygulamaları: Desteklenen Ürünler ve boyutlandırma
2015553 Microsoft Azure SAP: destek önkoşulları
1999351 SAP için gelişmiş Azure Izleme sorunlarını giderme
2178632 Microsoft Azure üzerinde SAP için anahtar Izleme ölçümleri
1409604 sanallaştırma Windows: gelişmiş izleme
2191498 Azure ile Linux üzerinde SAP: Gelişmiş Izleme
2243692 Linux on Microsoft Azure (ıaas) 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üklemesi ve yükseltmesi
1597355 Linux için takas boşluğu önerisi

Ayrıca, Linux için tüm SAP notlarını içeren SCN wiki 'yi de okuyun.

Bu makalede, genel varsayılan sınırlamalar ve Azure aboneliklerinin en yüksek sınırlamaları bulunabilir.

Olası senaryolar

SAP, genellikle kuruluşlar içindeki en önemli iş uygulamalarından biri olarak görülür. Bu uygulamaların mimarisi ve işlemleri çok karmaşıktır ve kullanılabilirlik ve performans açısından gereksinimleri karşıladığınızdan emin olmanızı sağlar.

Böylece kuruluşlar, üzerinde iş açısından kritik iş süreçlerini çalıştırmak için hangi bulut sağlayıcısının seçeceğini dikkatle düşünmeleri gerekir. Azure, iş açısından kritik SAP uygulamaları ve iş süreçlerine yönelik ideal genel bulut platformudur. Neredeyse tüm mevcut SAP NetWeaver ve S/4HANA sistemleri çok çeşitli Azure altyapısına sahip olmak üzere bugün Azure 'da barındırılabilir. Azure, çok sayıda terabayt belleği ve 200 ' den fazla CPU içeren VM 'Ler sağlar. Azure 'un ötesinde, 24 TB 'a varan ve 120 TB 'a kadar genişleme dağıtım SAP HANA genişleme HANA dağıtımlarına izin veren Hana büyük örneklerisunmaktadır. Günümüzde, neredeyse tüm şirket içi SAP senaryolarının Azure 'da da çalıştırılabileceği bir durum olabilir.

Senaryolar ve desteklenmeyen bazı senaryolar hakkında kaba bir açıklama için bkz. Azure sanal makinesi desteklenen senaryolarda belge SAP iş yükü.

Bu senaryoları ve Azure 'a dağıtmak istediğiniz mimarinin planlanması ve geliştirilmesi sırasında başvurulan belgelerde desteklenmeyen olarak adlandırılan bazı koşulları denetleyin.

En yaygın dağıtım deseninin genel olarak gösterildiği gibi şirket içi bir senaryosu vardır

Siteden siteye bağlantısı olan VPN (Şirket içi)

Birçok müşterinin Şirket içi dağıtım modelini uygulama nedeni, tüm uygulamaların Azure ExpressRoute kullanarak şirket içinde Azure 'a genişletilmesi ve Azure 'u sanal veri merkezi olarak işlemesi için en çok saydam olmasının nedenidir. Daha fazla ve daha fazla varlık Azure 'a taşındıktan sonra, Azure dağıtılan altyapı ve ağ altyapısı büyür ve şirket içi varlıklar buna uygun şekilde azaltacaktır. Kullanıcılar ve uygulamalar tarafından saydam olan her şey.

SAP sistemlerini genel olarak Azure IaaS veya IaaS 'e başarıyla dağıtmak için geleneksel outsourcers veya barındırıcıların ve IaaS tekliflerinin teklifleri arasındaki önemli farklılıkları anlamak önemlidir. Geleneksel barındırıcı veya dış kaynaklar, bir müşterinin barındırmak istediği iş yüküne (ağ, depolama ve sunucu türü), bu da müşterinin iş yükünü niteleyen ve IaaS dağıtımları için VM, depolama ve ağ için doğru Azure bileşenlerini seçme sorumluluğunu karşılarken sağlar.

Dağıtımınızın Azure 'a planlanmasına yönelik verileri toplamak için şunları yapmanız gerekir:

  • Azure VM 'lerinde hangi SAP ürünlerinin çalıştığını değerlendirin
  • Bu SAP ürünleri için belirli Azure VM 'leriyle hangi Işletim sistemi sürümlerinin desteklendiğini değerlendirin
  • Belirli Azure VM 'Leri ile SAP ürünleriniz için hangi DBMS sürümlerinin desteklendiğini değerlendirin
  • Desteklenen bir yapılandırmaya ulaşmak için gerekli işletim sistemi/DBMS sürümlerinin bazılarının SAP sürümü, destek paketi yükseltmesi ve çekirdek yükseltmeleri gerçekleştirmenizi isteyip istemediğinizi değerlendirin
  • Azure 'da dağıtmak için farklı işletim sistemlerine geçiş yapmanız gerekip gerekmediğini değerlendirin.

Azure 'da desteklenen SAP bileşenleriyle ilgili ayrıntılar, desteklenen Azure altyapı birimleri ve ilgili işletim sistemi yayınları ve DBMS sürümleri, Azure dağıtımları Için HANGI SAP yazılımının desteklenmemakalesinde açıklanmaktadır. Geçerli SAP sürümlerinin, işletim sisteminin ve DBMS sürümlerinin değerlendirmesinden elde edilen sonuçlar, SAP sistemlerini Azure 'a taşıma çabalarına büyük bir etkiye sahiptir. Bu değerlendirmeden elde edilen sonuçlar, SAP sürüm yükseltmelerinde veya işletim sistemlerindeki değişikliklerin gerekli olduğu durumlarda önemli hazırlık çabalarına sahip olup olmadığını tanımlamaktır.

Azure bölgeleri

Microsoft 'un Azure hizmetleri Azure bölgelerinde toplanır. Azure bölgesi, farklı Azure hizmetlerini barındıran ve çalıştıran donanım ve altyapıyı içeren bir veya veri merkezinden oluşan bir koleksiyondur. Bu altyapı, işlem düğümleri veya depolama düğümleri olarak çalışan çok sayıda düğüm içerir veya ağ işlevselliği çalıştırır.

Farklı Azure bölgelerinin bir listesi için Azure coğrafi graflarınıgözden geçirin. Tüm Azure bölgeleri aynı hizmetleri sunmaz. Çalıştırmak istediğiniz SAP ürününe ve onunla ilgili işletim sistemi ve DBMS 'ye bağlı olarak, belirli bir bölgenin ihtiyacınız olan sanal makine türlerini sunmadığından bir durum ortaya çıkabilir. Bu, genelde, genellikle e/Mv2 VM Serisi VM 'lerinin olması gereken SAP HANA çalıştırmak için geçerlidir. Bu VM aileleri yalnızca bölgelerin bir alt kümesinde dağıtılır. Bölgeye göre kullanılabilir site ürünlerininyardım 'ına sahip BÖLGELERIN hangi VM, tür, Azure depolama türü veya diğer Azure hizmetlerinin kullanılabilir olduğunu bulabilirsiniz. Planlamanızı başlattığınızda ve birincil bölge ve sonunda ikincil bölge olarak belirli bölgelere göz önünde bulundurmanız durumunda, önce gerekli hizmetlerin bu bölgelerde kullanılabilir olup olmadığını araştırmanız gerekir.

Kullanılabilirlik Alanları

Azure bölgelerinin birkaçı Kullanılabilirlik Alanları adlı bir kavram uyguladık. Kullanılabilirlik Alanları bir Azure bölgesindeki fiziksel konumlardan farklıdır. Her Kullanılabilirlik Alanı bağımsız enerji, soğutma ve ağ kaynaklarıyla donatılmış bir veya daha fazla veri merkezinden oluşur. Örneğin, iki sanal makineyi Azure 'un iki Kullanılabilirlik Alanları arasında dağıtma ve SAP DBMS sisteminiz için yüksek kullanılabilirlik çerçevesi uygulama veya SAP Merkezi Hizmetleri, Azure 'da en iyi SLA 'yı sağlar. Azure 'daki bu belirli sanal makine SLA 'Sı için, sanal makineSLA 'larının en son sürümünü denetleyin. Azure bölgelerinin son yıllarda hızla geliştirildiği ve uzadığından, Azure bölgelerinin topolojisi, fiziksel veri merkezlerinin sayısı, bu veri merkezleri arasındaki mesafe ve Azure Kullanılabilirlik Alanları arasındaki mesafe farklı olabilir. Ve ile ağ gecikmesi.

Kullanılabilirlik Alanları prensibi, Hana büyük örneklerindekiHana 'ya özgü hizmet için geçerlidir. HANA büyük örneklerine yönelik hizmet düzeyi sözleşmeleri Azure üzerinde SAP HANA büyük örnekleri Için SLA makalesinde bulunabilir

Hata etki alanları

Hata etki alanları, veri merkezlerinde bulunan fiziksel altyapıyla yakından ilişkili olan fiziksel bir hata birimini temsil eder ve bir fiziksel dikey pencere veya raf bir hata etki alanı olarak kabul edildiğinde, ikisi arasında doğrudan bire bir eşleme yoktur.

birden çok sanal makineyi Microsoft Azure sanal makine hizmetleri ' nde bir SAP sisteminin bir parçası olarak dağıttığınızda, uygulamanızı farklı hata etki alanlarına dağıtmak için Azure yapı denetleyicisi ' ni etkileyebilir ve böylece daha yüksek kullanılabilirlik sla 'ları daha yüksektir. ancak, bir 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ılması veya vm 'lerin belirli bir hata etki alanına atanması, doğrudan denetime sahip olduğunuz bir şeydir. Azure yapı denetleyicisi 'ni farklı hata etki alanları üzerinden bir VM kümesi dağıtmak üzere yönlendirmek için, dağıtım zamanında VM 'lere bir Azure kullanılabilirlik kümesi atamanız gerekir. Azure kullanılabilirlik kümeleri hakkında daha fazla bilgi için bu belgedeki bölüm Azure kullanılabilirlik kümeleri bölümüne bakın.

Yükseltme etki alanları

Yükseltme etki alanları, birden çok VM 'de çalışan SAP örneklerinden oluşan SAP sistemi içindeki bir VM 'nin nasıl güncelleştirileceğini belirlemede yardımcı olan bir mantıksal birimi temsil eder. bir yükseltme gerçekleştiğinde Microsoft Azure, bu yükseltme etki alanlarını tek tek güncelleştirme sürecindedir. VM 'Leri dağıtım zamanında farklı yükseltme etki alanları üzerinden yayarak, SAP sisteminizi kısmen olası kapalı kalma süresinden koruyabilirsiniz. Azure 'u, farklı yükseltme etki alanları üzerinden SAP sisteminin sanal makinelerini dağıtmaya zorlamak için, her bir VM 'nin dağıtım zamanında belirli bir öznitelik ayarlamanız gerekir. Hata etki alanlarına benzer şekilde, Azure ölçek birimi birden fazla yükseltme etki alanına bölünmüştür. Azure yapı denetleyicisi 'ni farklı yükseltme etki alanları üzerinden bir VM kümesi dağıtmak üzere yönlendirmek için, dağıtım zamanında VM 'lere bir Azure kullanılabilirlik kümesi atamanız gerekir. Azure kullanılabilirlik kümeleri hakkında daha fazla bilgi için aşağıdaki bölüm Azure kullanılabilirlik kümeleri bölümüne bakın.

Azure kullanılabilirlik kümeleri

Tek bir Azure kullanılabilirlik kümesindeki Azure sanal makineleri, farklı hata ve yükseltme etki alanları üzerinden Azure yapı denetleyicisi tarafından dağıtılır. Farklı hata ve yükseltme etki alanları üzerinden dağıtımın amacı, bir SAP sisteminin tüm VM 'lerinin altyapı bakımı veya bir hata etki alanındaki bir hata durumunda kapatılmasını önlemektir. Varsayılan olarak, VM 'Ler bir kullanılabilirlik kümesinin parçası değildir. Bir VM 'nin bir kullanılabilirlik kümesinde katılımı, bir VM 'nin yeniden yapılandırılması ve yeniden dağıtılması ile dağıtım sırasında veya sonrasında tanımlanır.

Azure kullanılabilirlik kümeleri kavramını ve kullanılabilirlik kümelerinin hata ve yükseltme etki alanlarıyla ilişkisini anlamak için Bu makaleyiokuyun.

Kullanılabilirlik kümelerini tanımladığınızda ve tek bir kullanılabilirlik kümesi içinde farklı VM ailelerinin çeşitli sanal makinelerini karışmaya çalıştığınızda, bu tür bir kullanılabilirlik kümesine belirli bir sanal makine türü dahil etmeniz için sorunlarla karşılaşabilirsiniz. Bunun nedeni, kullanılabilirlik kümesinin belirli bir işlem Konakları türü içeren ölçek birimine bağlanmasının nedenidir. Ve belirli türde bir işlem konağı yalnızca belirli türlerde VM aileleri çalıştırabilir. Örneğin, bir kullanılabilirlik kümesi oluşturur ve ilk VM 'yi kullanılabilirlik kümesine dağıtırsanız ve Esv3 ailesinin bir VM türünü seçip ikinci VM olarak bir M ailesinin VM 'si olarak dağıtmayı denerseniz, ikinci ayırmada ret edilir. Bunun nedeni, Esv3 ailesi VM 'lerinin M ailesinin sanal makinelerle aynı ana bilgisayar donanımında çalışmadığı nedenidir. Aynı sorun, VM 'Leri yeniden boyutlandırmaya çalışırken ve bir VM 'yi Esv3 ailesinden M ailesinin bir sanal makine türüne taşımaya çalıştığınızda meydana gelebilir. Aynı konak donanımında barındırılmayan bir VM ailesine yeniden boyutlandırma durumunda, kullanılabilirlik kümesindeki tüm VM 'Leri kapatmanız ve diğer ana makine türünde çalıştırabilmek için yeniden boyutlandırmanız gerekir. Kullanılabilirlik kümesi içinde dağıtılan VM 'lerin SLA 'ları için sanal makine SLA 'larımakalesine bakın.

Kullanılabilirlik kümesi ve ilgili güncelleştirme ve hata etki alanı prensibi, Hana büyük örnekHana 'ya özgü hizmet için geçerlidir. HANA büyük örneklerine yönelik hizmet düzeyi sözleşmeleri, Azure üzerinde SAP HANA büyük örnekleri Için SLAmakalesinde bulunabilir.

Önemli

Azure Kullanılabilirlik Alanları ve Azure kullanılabilirlik kümelerinin kavramları birbirini dışlıyor. Yani, bir çift veya birden çok VM 'yi belirli bir kullanılabilirlik alanına veya Azure kullanılabilirlik kümesine dağıtabileceğiniz anlamına gelir. Ancak ikisini birden değil.

Azure eşlenmiş bölgeler

Azure, bu sabit bölge çiftleri arasında belirli verilerin çoğaltılmasının etkinleştirildiği Azure bölge çiftlerini sunmaktadır. Bölge eşleştirme, iş sürekliliği ve olağanüstü durum kurtarma (BCDR) makalesinde belgelenmiştir: Azure eşleştirilmiş bölgeleri. Makalede açıklandığı gibi, verilerin çoğaltılması, eşleştirilmiş bölgeye çoğaltmak için sizin tarafınızdan yapılandırılabilen Azure Depolama türleri ile bağlantılıdır. ayrıca bkz. bir ikincil bölgedeki artıklık Depolama. Böyle bir çoğaltmaya izin veren Depolama türleri, DBMS iş yükü için uygun olmayan depolama türlerdir. Bu nedenle, Azure depolama çoğaltma 'nın kullanılabilirliği Azure Blob depolama (yedekleme amaçları için) veya diğer yüksek gecikmeli depolama senaryolarında sınırlı olacaktır. Eşleştirilmiş bölgeleri ve birincil veya ikincil bölgeniz olarak kullanmak istediğiniz hizmetleri denetlebildiğiniz için, birincil bölgenizde kullanmayı düşündüğünüz Azure hizmetlerinin ve/veya VM türlerinin eşleştirilmiş bölgede kullanılamadığı durumlarla karşılaşabilirsiniz. Ya da Azure eşlenmiş bölgesinin veri uyumluluğun kabul edilebileceği bir durumla karşılaşabilirsiniz. Bu gibi durumlarda, eşlenmiş olmayan bir bölgeyi ikincil/olağanüstü durum kurtarma bölgesi olarak kullanmanız gerekir. Böyle bir durumda, Azure 'un kendi çoğaltmasıyla ilgili verilerden bazılarının çoğaltılmasını dikkatli olmanız gerekir. Active Directory ve DNS 'nizi olağanüstü durum kurtarma bölgenize nasıl çoğaltacağınız hakkında bir örnek, Active Directory ve DNS için olağanüstü durum kurtarma kurulumu makalesinde açıklanmaktadır.

Azure sanal makine Hizmetleri

Azure, dağıtmayı seçebileceğiniz çok çeşitli sanal makineler sunar. Ön teknoloji ve altyapı satın alımlarına gerek yoktur. Azure VM hizmeti teklifi, Web uygulamasını ve bağlı uygulamaları barındırmak, ölçeklendirmek ve yönetmek için isteğe bağlı bilgi işlem ve depolama sağlayarak uygulamaların sürdürülmesi ve işletim sistemlerini basitleştirir. Altyapı yönetimi, birçok farklı fiyatlandırma modeli seçeneğiyle, kullanım ihtiyaçlarını karşılamak için yüksek kullanılabilirlik ve dinamik ölçeklendirme için tasarlanan bir platform ile otomatiktir.

Microsoft Azure sanal makine hizmetleri 'nin konumlandırması

Azure sanal makineler ile Microsoft, özel sunucu görüntülerini IaaS örnekleri olarak Azure 'a dağıtmanızı sağlar. Ya da Azure görüntü galerisindeki çok sayıda tüketilebilir işletim sistemi görüntüsü arasından seçim yapabilirsiniz.

Azure sanal makine hizmeti, işlemsel bir perspektiften, şirket içinde dağıtılan sanal makineler gibi benzer deneyimler sağlar. Yönetim, işlemler ve ayrıca söz konusu işletim sisteminin bir Azure VM 'de ve bu VM 'deki uygulamalarında çalışan düzeltme eki uygulama sorumluluğu size yöneliktir. Microsoft, bu VM 'yi Azure altyapısında barındırmanın ötesinde daha fazla hizmet sağlamıyor (hizmet olarak altyapı-IaaS). Müşteri dağıtımı olarak kullandığınız SAP iş yükü için, Microsoft 'un IaaS tekliflerinin ötesinde hiçbir teklifi yoktur.

Microsoft Azure platformu çok kiracılı bir platformdur. Sonuç olarak, Azure VM 'Leri barındıran depolama, ağ ve işlem kaynakları, kiracılar arasında paylaşılan birkaç özel durum ile sağlanır. Akıllı daraltma ve kota mantığı, bir kiracının başka bir kiracının (gürültülü komşu) performansını farklı bir şekilde etkileyerek engel olmak için kullanılır. Özellikle SAP HANA için Azure platformunu sertifikalamak için, Microsoft 'un, birden çok VM 'nin aynı konakta SAP 'ye düzenli olarak çalıştırılabileceği durumlarda kaynak yalıtımını kanıtlamasını sağlaması gerekir. Azure 'daki mantığın bant genişliğine karşı küçük, çok az paylaşılan platformlar, kaynakların şirket içi dağıtımlarıyla karşılaşabileceğine göre kaynak/bant genişliği kullanılabilirliği bölümünde daha büyük farklar ortaya çıkaracak şekilde çalışır. Azure üzerindeki bir SAP sisteminin, şirket içi bir sistem tarafından daha büyük farklar yaşayabileceğiniz, hesaba alınması olasılığı vardır.

SAP iş yükü için Azure sanal makineleri

SAP iş yükü için seçimi, SAP iş yükü ve SAP HANA iş yükü için uygun olan farklı VM ailelerine doğru şekilde kapattık. Doğru sanal makine türünü ve SAP iş yükü aracılığıyla çalışma özelliğini nasıl bulacağınız, Azure dağıtımları Için HANGI SAP yazılımlarının desteklendiğibelgede açıklanmaktadır.

Not

SAP iş yükü için sertifikalı VM türleri, CPU ve bellek kaynaklarının aşırı sağlanması değildir.

Yalnızca desteklenen VM türlerinin seçiminin ötesinde, bu VM türlerinin, bölgeye göre kullanılabilir site ürünlerinitemel alan belirli bir bölgede kullanılabilir olup olmadığını da denetlemeniz gerekir. Ancak daha fazla önemli olsun, şunları değerlendirmeniz gerekir:

  • Farklı VM türlerindeki CPU ve bellek kaynakları
  • Farklı VM türlerindeki ıOPS bant genişliği
  • Farklı VM türlerinin ağ özellikleri
  • İliştirilebilecek disk sayısı
  • Belirli Azure depolama türlerinden yararlanma olanağı

gereksinimlerinize uygun hale getirmeniz yeterlidir. bu verilerin çoğu, belirli bir sanal makine türü için burada (Linux) ve burada (Windows) bulunabilir.

Fiyatlandırma modeli olarak, aşağıda gösterildiği gibi çeşitli farklı fiyatlandırma seçeneklerine sahip olursunuz:

  • Kullandıkça öde
  • Bir yıl ayrılmış
  • Üç yıl ayrılmış
  • Spot fiyatlandırması

farklı hizmet sunan farklı hizmet tekliflerindeki her birinin fiyatlandırması, site Linux Sanal Makineleri fiyatlandırması ve Windows Sanal Makineleri fiyatlandırmasındakullanılabilir. Bir yıl ve üç yıllık ayrılmış örnek için Ayrıntılar ve esneklik için şu makalelere bakın:

Spot fiyatlandırma hakkında daha fazla bilgi için Azure spot sanal makinelermakalesini okuyun. Aynı VM türünün fiyatlandırması farklı Azure bölgeleri arasında da farklı olabilir. Bazı müşteriler için daha az maliyetli bir Azure bölgesine dağıtılması gerekir.

Ayrıca, Azure adanmış bir konağın kavramlarını da sunmaktadır. Adanmış konak kavramı, Azure tarafından gerçekleştirilen düzeltme eki uygulama döngülerinde daha fazla denetim sağlar. Düzeltme eki uygulama, kendi zamanlamalarınız doğrultusunda zaman alabilir. Bu teklif, müşterileri normal iş yükü döngüsünü izleyemeyebilir iş yüküne yönelik olarak hedefler. Azure ayrılmış ana bilgisayar teklifleri kavramlarını okumak için, Azure adanmış ana bilgisayarmakalesini okuyun. Bu teklifin kullanılması SAP iş yükü için desteklenir ve altyapı ve Microsoft 'un nihai bakım planları üzerinde daha fazla denetime sahip olmak isteyen çeşitli SAP müşterileri tarafından kullanılır. Microsoft 'un sanal makineleri barındıran Azure altyapısını nasıl koruduğu ve düzeltme eklerinin bulunduğu hakkında daha fazla bilgi için, Azure 'da sanal makineler Için bakımmakalesini okuyun.

1. nesil ve 2. nesil sanal makineler

Microsoft 'un Hiper Yöneticisi iki farklı nesil sanal makineyi işleyebilir. Bu biçimler 1. kuşak ve 2. nesil olarak adlandırılır. 2. nesil 2012 yılında Windows Server 2012 hiper yöneticiyle tanıtılmıştı. Azure, 1. nesil sanal makineler kullanarak başladı. Azure sanal makinelerini dağıtırken, varsayılan olarak 1. kuşak biçimini kullanmaya devam etmektedir. Ayrıca 2. nesil VM biçimlerini de dağıtabilirsiniz. Azure üzerinde 2. nesil VM 'ler Için destek makalesinde 2. nesil VM olarak DAĞıTıLABILECEK Azure VM aileleri listelenir. Bu makalede ayrıca, 2. nesil sanal makinelerin Hyper-V özel bulutu ve Azure üzerinde çalıştırılabilen önemli işlevsel farklılıkları listelenmektedir. Daha önemli bu makalede, 1. nesil sanal makineler ve 2. nesil VM 'Ler arasındaki işlevsel farklılıklar Azure 'da çalıştırılanlar için de listelenmiştir.

Not

Azure 'da çalışan 1. nesil ve 2. nesil VM 'lerin işlevsel farklılıkları vardır. Bu farklılıkların bir listesini görmek için Azure 'da 2. nesil VM 'ler Için destek makalesini okuyun.

Var olan bir VM 'yi bir nesle başka bir nesle taşımak mümkün değildir. Sanal makine üretimini değiştirmek için, oluşturma işlemi için gereken yeni bir VM 'yi dağıtmanız ve neslin sanal makinesinde çalıştırdığınız yazılımı yeniden yüklemeniz gerekir. Bu değişiklik yalnızca VM 'nin temel VHD görüntüsünü etkiler ve veri diskleri veya bağlı NFS ya da SMB paylaşımlarını etkilemez. Örneğin, 1. nesil bir VM 'de, başlangıçta atanan veri diskleri, NFS veya SMB paylaşımları.

Not

2020 Mayıs 'un başlangıcından itibaren 2. nesil sanal makineler olarak Mv1 VM ailesi VM 'Leri dağıtmak mümkündür. Bu şekilde, Mv1 ve Mv2 ailesi sanal makineleri arasında daha az bir değer azaltmak ve azaltmak mümkündür.

Depolama: Microsoft Azure Depolama ve veri diskleri

Microsoft Azure Sanal makineler farklı depolama türlerini kullanır. SAP 'yi Azure sanal makine Hizmetleri 'nde uygularken, bu iki ana depolama türü arasındaki farklılıkları anlamak önemlidir:

  • Kalıcı olmayan, geçici depolama.
  • Kalıcı depolama alanı.

VM dağıtıldıktan sonra Azure VM 'Ler kalıcı olmayan diskler sunar. VM 'nin yeniden başlatılması durumunda, bu sürücülerdeki tüm içerikler silinir. Bu nedenle, veri dosyaları ve veritabanlarının günlük/yineleme dosyalarının, kalıcı olmayan sürücülerde hiçbir koşul olmaması gerekir. Bu kalıcı olmayan sürücülerin tempdb ve temp Tablespaces için uygun olabileceği bazı veritabanları için özel durumlar olabilir. Ancak, bu diskleri kalıcı olmayan bir VM 'Ler için kullanmaktan kaçının çünkü bu kalıcı olmayan sürücüler bu VM ailesiyle üretilen iş ile sınırlıdır. daha fazla ayrıntı için Azure 'da Windows vm 'lerde geçici sürücüyü anlama makalesini okuyun


Windows logo. Windows

Sürücü D:\ Azure VM 'de, Azure işlem düğümündeki bazı yerel diskler tarafından desteklenen kalıcı olmayan bir sürücüdür. Kalıcı olmadığı için bu, D:\ ' deki içerikte yapılan tüm değişikliklerin yapıldığı anlamına gelir. VM yeniden başlatıldığında sürücü kaybedilir. "Tüm değişiklikler", depolanan dosyalar, oluşturulan dizinler, yüklü uygulamalar vb. gibi.

Linux logosu. Linux

Linux Azure VM 'Leri, Azure işlem düğümündeki yerel disklerle desteklenen kalıcı olmayan bir sürücü olan/mnt/Resource dizininde otomatik olarak bir sürücü bağlayabilir. Kalıcı olmadığı için bu,/mnt/Resource dosyasındaki içerikte yapılan tüm değişikliklerin VM yeniden başlatıldığında kaybedildiği anlamına gelir. Depolanan dosyalar, oluşturulan dizinler, yüklü uygulamalar vb. gibi değişiklikler tarafından yapılır.

Azure Depolama hesapları

azure 'da hizmet veya vm 'leri dağıttığınızda, vhd 'lerin ve vm görüntülerinin dağıtımı, azure Depolama hesapları olarak adlandırılan birimlerde düzenlenir. Azure depolama hesaplarının , IOPS, aktarım hızı veya içerdikleri boyutlarda sınırlamaları vardır. Geçmişte belgelenen Bu sınırlamalar:

Azure 'da SAP dağıtımı planlarken önemli bir rol yürütülüm. Bir depolama hesabındaki kalıcı disklerin sayısını yönettiğinizde. Depolama hesaplarını yönetmeniz ve sonunda daha kalıcı diskler oluşturmak için yeni depolama hesapları oluşturmanız gerekir.

Son yıllarda, Azure yönetilen disklerin tanıtımı sizi bu görevlerden daha fazla karşılamış. SAP dağıtımları için öneri, Azure depolama hesaplarını kendiniz yönetmek yerine Azure tarafından yönetilen disklerden faydalanır. Azure yönetilen diskler, diskler farklı depolama hesaplarına dağıtılır, bu nedenle ayrı depolama hesaplarının sınırları aşılmaz.

Bir depolama hesabı içinde, belirli diskleri belirli kapsayıcılara gruplamak için kullanılabilecek ' kapsayıcılar ' adlı bir klasör kavramı türüne sahip olursunuz.

Azure 'da bir disk/VHD adı, Azure 'da VHD için benzersiz bir ad sağlaması gereken aşağıdaki adlandırma bağlantısını izler:

http(s)://<storage account name>.blob.core.windows.net/<container name>/<vhd name>

yukarıdaki dize, Azure Depolama depolanan diski/VHD 'yi benzersiz şekilde tanımlamalıdır.

Azure kalıcı depolama türleri

Azure, SAP iş yükü ve belirli SAP Stack bileşenleri için kullanılabilen çeşitli kalıcı depolama seçeneği sunar. Diğer ayrıntılar için SAP iş yükleri için Azure depolama belgesini okuyun.

Microsoft Azure Ağ

Microsoft Azure, SAP yazılımıyla gerçekleştirmek istediğiniz tüm senaryoların eşlemesini sağlayan bir ağ altyapısı sağlar. Özellikler:

  • Windows Terminal Hizmetleri veya ssh/VNC aracılığıyla doğrudan vm'lere dışarıdan erişim
  • VM'ler içindeki uygulamalar tarafından kullanılan hizmetlere ve belirli bağlantı noktalarına erişim
  • Azure VM'leri olarak dağıtılan bir grup VM arasında İç İletişim ve Ad Çözümlemesi
  • Müşterinin şirket içi ağı ile Azure ağı arasında Şirket İçi Ve Şirket İçi Bağlantı
  • Azure siteleri arasında Azure Bölgesi veya veri merkezi bağlantısı

Buradan daha fazla bilgi bulabilirsiniz: https://azure.microsoft.com/documentation/services/virtual-network/

Azure'da ad ve IP çözümlemesini yapılandırmak için birçok farklı olasılık vardır. Ayrıca kendi DNS Azure DNS yerine kullanılmaktadır. Bu makalede ve bu sayfada daha fazla bilgi bulunabilir.

Şirket içi veya karma senaryolar için şirket içi AD/OpenLDAP/DNS'nin VPN veya Azure'a özel bağlantı aracılığıyla genişletildiklerine güveneceğiz. Burada belgelenmiş olan bazı senaryolarda, Azure'da yüklü bir AD/OpenLDAP çoğaltması olması gerekebilir.

Ağ ve ad çözümlemesi bir SAP sistemi için veritabanı dağıtımının önemli bir parçası olduğundan, bu kavram DBMS Dağıtım Kılavuzu'nda daha ayrıntılı olarak ele alınmıştır.

Azure Sanal Ağları

Bir Azure Sanal Ağı yapılandırarak, Azure DHCP işlevselliği tarafından ayrılan özel IP adreslerinin adres aralığını tanımlayabilirsiniz. Şirket içi ve dışı senaryolarda tanımlanan IP adresi aralığı, Azure tarafından DHCP kullanılarak hala ayrılır. Ancak, Etki Alanı Adı çözümlemesi şirket içinde yapılır (VM'lerin bir şirket içi etki alanının parçası olduğu varsaysak) ve bu nedenle adresleri farklı etki alanlarının ötesinde Azure Cloud Services.

Azure'daki her Sanal Makinenin bir Sanal Ağa bağlı olması gerekir.

Daha fazla ayrıntı bu makalede ve bu sayfada bulunabilir.

Not

Varsayılan olarak, bir VM dağıtıldıktan sonra Sanal Ağ yapılandırmasını değiştiremezsiniz. TCP/IP ayarları Azure DHCP sunucusuna bırak gerekir. Varsayılan davranış Dinamik IP atamadır.

Sanal ağ kartının MAC adresi değişebilir, örneğin yeniden boyutlandırmadan sonra ve Windows veya Linux konuk işletim sistemi yeni ağ kartını alır ve bu durumda IP ve DNS adreslerini atamak için otomatik olarak DHCP kullanır.

Statik IP Ataması

Bir Azure Sanal Ağı içindeki VM'lere sabit veya ayrılmış IP adresleri atamak mümkündür. Vm'leri bir Azure Sanal Ağına çalıştırmanız, bazı senaryolar için gerekirse veya gerektiğinde bu işlevden yararlanabilirsiniz. IP ataması, VM'nin çalışma veya kapatmadan bağımsız olarak VM'nin varlığı boyunca geçerli kalır. Sonuç olarak, Sanal Ağ için IP adresi aralığını tanımlarken genel VM sayısını (çalışan ve durdurulmuş VM'ler) hesaba kabul etmek gerekir. VM ve Ağ Arabirimi silinene kadar veya IP adresi yeniden atanana kadar IP adresi atanmış olarak kalır. Daha fazla bilgi için bu makaleyi okuyun.

Not

Tek tek vNC'lere Azure üzerinden statik IP adresleri atamanız gerekir. Konuk işletim sistemi içindeki statik IP adreslerini bir vNIC'ye atamamanız gerekir. Azure Backup Service gibi bazı Azure hizmetleri, statik IP adreslerine değil, en azından birincil vNIC'nin DHCP'ye ayarlanıyor olması gerçeğine güvenmektedir. Azure sanal makine yedekleme sorunlarını giderme belgesine de bakın.

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

Her Azure Sanal Makinesinin ağ arabirimi kartına birden çok IP adresi atanabilir. Bu ikincil IP, gerekirse DNS A/PTR kaydıyla eşlenen SAP sanal ana bilgisayar adlarına kullanılabilir. İkincil IP adresleri, bu makaleye göre Azure vNICs IP yapılandırmasına atanmalı ve ikincil IP'ler DHCP üzerinden atanmadığı için işletim sistemi içinde yapılandırıldı. Her ikincil IP, vNIC'nin bağlı olduğu aynı alt ağdan olmalı. Pacemaker Azure Load Balancer gibi ikincil IP yapılandırmaları için Load Balancer'nin kayan IP'sini kullanma ikincil olarak desteklenmez. Bu durumda Load Balancer IP'leri SAP sanal konak adlarına olanak sağlar. Ayrıca bkz. Sanal ana bilgisayar adlarını 962955 genel kılavuz hakkında SAP'nin notunu ve daha fazla bilgi.

VM başına birden çok NIC

Bir Azure Sanal Makinesi için birden çok sanal ağ arabirimi kartı (vNIC) tanımlayabilirsiniz. Birden çok vNIC'ye sahip olmak özelliğiyle, örneğin istemci trafiğinin bir vNIC üzerinden ve arka uç trafiğinin ikinci bir vNIC üzerinden yönlendirilen ağ trafiği ayrımını ayarlamaya başlayabilirsiniz. VM türüne bağlı olarak, bir VM'nin atadığı sanal makine sayısı için farklı sınırlamalar vardır. Tam ayrıntılar, işlevler ve kısıtlamalar şu makalelerde bulunabilir:

Siteden Siteye Bağlantı

Şirket içi ve şirket içi, saydam ve kalıcı bir VPN bağlantısıyla bağlantılı Azure VM'leri ve Şirket içidir. Azure'da en yaygın SAP dağıtım modeli olması beklenir. Varsayım, Azure'daki SAP örnekleriyle işlem yordamları ve işlemlerin şeffaf bir şekilde çalışması gerektiğidir. Bu, bu sistemlerden yazdırma ve SAP Transport Management System (TMS) kullanarak değişiklikleri Azure'daki bir geliştirme sisteminden şirket içinde dağıtılan bir test sistemine taşımanız gerektiği anlamına gelir. Siteden siteye hakkında daha fazla belge bu makalede bulunabilir

VPN Tunnel Cihazı

Siteden siteye bağlantı oluşturmak için (şirket içi veri merkezinden Azure veri merkezine) bir VPN cihazı edinecek ve yapılandırabilirsiniz ya da Windows Server 2012 ile yazılım bileşeni olarak tanıtılan Yönlendirme ve Uzaktan Erişim Hizmeti'Windows Server 2012.

Şirket içi ile Azure arasında siteden siteye bağlantı

Yukarıdaki şekilde iki Azure aboneliğinin Azure'daki Sanal Ağlarda kullanım için ayrılmış IP adresi alt düzenleri vardır. Şirket içi ağdan Azure'a bağlantı VPN üzerinden kurulur.

Noktadan Siteye VPN

Noktadan siteye VPN, her istemci makinenin kendi VPN'sini Azure'a bağlamasını gerektirir. SAP senaryolarında noktadan siteye bağlantının pratik olmadığını arıyoruz. Bu nedenle noktadan siteye VPN bağlantısına başka başvurular verilmemektedir.

Daha fazla bilgi için buraya bakın

Çok Siteli VPN

Azure ayrıca günümüzde tek bir Azure aboneliği için Çok Siteli VPN bağlantısı oluşturma olanağı sunar. Daha önce tek bir abonelik, tek bir siteden siteye VPN bağlantısıyla sınırlıydı. Bu sınırlama, tek bir abonelik için Çok Siteli VPN bağlantıları nedeniyle sona edi. Bu, şirket içi ve şirket içi yapılandırmalar aracılığıyla belirli bir abonelik için birden fazla Azure Bölgesi'nden faydalanmanizi sağlar.

Daha fazla belge için bu makaleye bakın

Sanal Ağdan Sanal Ağ bağlantısına

Çok Siteli VPN kullanarak, bölgelerin her biri için ayrı bir Azure Ağa gelen yapılandırmanız gerekir. Ancak genellikle farklı bölgelerdeki yazılım bileşenlerinin birbirleriyle iletişim kurması gerekir. İdeal olan bu iletişimin bir Azure Bölgesinden şirket içi bölgeye ve buradan diğer Azure Bölgesi'ne yönlendirilene kadar yönlendirilene bir bağlantı olmasıdır. Kısayol için Azure, bir Azure Sanal Ağı'Ağa gelen başka bir bölgede barındırılan başka bir Azure Sanal Ağına bağlantı yapılandırma olanağı sunar. Bu işlev VNet-VNet bağlantısı olarak adlandırılan bir özelliktir. Bu işlevle ilgili daha fazla ayrıntıya buradan bakabilirsiniz: https://azure.microsoft.com/documentation/articles/vpn-gateway-vnet-vnet-rm-ps/ .

Azure ExpressRoute'a Özel Bağlantı

Microsoft Azure ExpressRoute, Azure veri merkezleri ile müşterinin şirket içi altyapısı veya ortak konum ortamında özel bağlantılar oluşturulmasına olanak sağlar. ExpressRoute, çeşitli MPLS (paket anahtarlı) VPN sağlayıcıları veya diğer Ağ Hizmeti Sağlayıcıları tarafından sunulur. ExpressRoute bağlantıları ortak İnternet üzerinden geçmemektedir. ExpressRoute bağlantıları, İnternet üzerinden yapılan tipik bağlantılara göre daha yüksek güvenlik, birden çok paralel bağlantı hattı üzerinden daha yüksek güvenilirlik, daha yüksek hızlar ve daha düşük gecikme süreleri sunar.

Teklif ve teklifler hakkında daha Azure ExpressRoute burada bulabilirsiniz:

Express Route, burada belgelenmiş olan bir ExpressRoute bağlantı hattı üzerinden birden çok Azure aboneliğini sağlar

Şirket içi ve şirket içi ve şirket içi durumlarında zorlamalı tünel

Siteden siteye, noktadan siteye veya ExpressRoute aracılığıyla şirket içi etki alanlarına katılan VM'ler için, İnternet proxy ayarlarının bu VM'lerde tüm kullanıcılar için de dağıtıldığından emin olun. Varsayılan olarak, bu VM'lerde çalışan yazılımlar veya İnternet'e erişmek için tarayıcı kullanan kullanıcılar şirket ara sunucusu üzerinden değil, doğrudan Azure üzerinden İnternet'e bağlanıyor olabilir. Ancak ara sunucu ayarı bile trafiği şirket ara sunucusu üzerinden yönlendiren %100 çözüm değildir çünkü ara sunucu denetimi yazılım ve hizmetlerin sorumluluğundadır. VM'de çalışan yazılımlar bunu yapmıyorsa veya bir yönetici ayarları yönetene kadar İnternet'e gelen trafik, Azure üzerinden doğrudan İnternet'e yeniden yönlendiri.

Böyle bir doğrudan İnternet bağlantısından kaçınmak için Şirket içi ile Azure arasında siteden siteye bağlantı ile Zorlamalı Tünel Yapılandırabilirsiniz. Zorlamalı Tünel özelliğinin ayrıntılı açıklaması burada yayımlanır https://azure.microsoft.com/documentation/articles/vpn-gateway-forced-tunneling-rm/

ExpressRoute ile Zorlamalı Tünel, ExpressRoute BGP eşleme oturumları aracılığıyla varsayılan bir yol tanıtımları tarafından etkinleştirilir.

Azure ağının özeti

Bu bölümde, veri noktalarıyla ilgili birçok önemli Azure Ağ. Ana noktaların özeti şu şekildedir:

  • Azure Sanal Ağları, Azure dağıtımınıza bir ağ yapısı koymanıza olanak sağlar. VNet'ler birbirlerine karşı yalıtılmış olabilir veya sanal ağ arasındaki Ağ Güvenlik Grupları trafiği denetlenenin yardımıyla.
  • Azure Sanal Ağları, VM'lere IP adresi aralıkları atamak veya VM'lere sabit IP adresleri atamak için kullanılabilir
  • Siteden Siteye veya Noktadan Siteye bağlantı ayarlamak için önce bir Azure Sanal Ağı oluşturmanız gerekir
  • Bir sanal makine dağıtıldıktan sonra, vm'ye atanan Sanal Ağı değiştirmek artık mümkün değildir

Azure sanal makine hizmet kotaları

Depolama ve ağ altyapısının Azure altyapısında çeşitli hizmetleri çalıştıran VM'ler arasında paylaştırılıyor olduğunu net bir şekilde ifade etmek gerekir. Müşterinin kendi veri merkezlerinde olduğu gibi, bazı altyapı kaynaklarının fazla sağlanması bir ölçüde uzıyor. Microsoft Azure Platformu, kaynak tüketimini sınırlamak ve tutarlı ve belirlenebilir performansı korumak için disk, CPU, ağ ve diğer kotaları kullanır. Farklı VM türleri (A5, A6 vb.) disk sayısı, CPU, RAM ve Ağ için farklı kotalara sahiptir.

Not

SAP tarafından desteklenen VM türlerinin CPU ve bellek kaynakları konak düğümlerinde önceden ayrılır. Bu, VM dağıtıldıktan sonra konakta kaynakların VM türüne göre tanımlandığı şekilde kullanılabilir olduğu anlamına gelir.

Çözüm planlama ve boyutlandırma Azure üzerinde SAP, her sanal makine boyutuna yönelik kotalar dikkate alınmalıdır. VM kotaları burada (Linux) ve burada açıklanmıştır (Windows).

Açıklanan kotalar teorik maksimum değerleri temsil eder. Disk başına IOPS sınırına küçük işletim sistemi (8 KB) ile ulaşabilirsiniz ancak büyük ölçekli işletim sistemi (1 MB) ile bu sınıra ulaşılamayabilirsiniz. IOPS sınırı, tek bir diskin tanecikliği üzerinde uygulanır.

Sap sisteminin Azure Sanal Makine Hizmetleri'ne ve özelliklerine uygun olup olmadığını veya sistemi Azure'a dağıtmak için mevcut bir sistemin farklı yapılandırılması gerekip gerek olmadığını karara varan kaba bir karar ağacı olarak aşağıdaki karar ağacı kullanılabilir:

Dağıtım yeteneğine karar vermek için karar ağacı Azure üzerinde SAP

  1. Başlangıç olarak en önemli bilgiler, verilen bir SAP sistemi için SAPS gereksinimidir. SAP sistemi şirket içinde 2 katmanlı bir yapılandırmada dağıtılmış olsa bile SAPS gereksinimlerinin DBMS bölümü ve SAP uygulama bölümü olarak ayrılması gerekir. Mevcut sistemlerde, kullanımda olan donanımla ilgili SAPS genellikle mevcut SAP kıyaslamalarına göre belirlen veya tahmin edile bir sistemdir. Sonuçları SAP Standart Uygulama Karşılaştırmaları Hakkında sayfasında bulabilirsiniz. Yeni dağıtılan SAP sistemleri için sistemin SAPS gereksinimlerini belirleyen bir boyutlandırma alıştırması tamamlamış olması gerekir.
  2. Mevcut sistemlerde, DBMS sunucusundaki saniye başına I/O birimi ve I/O işlemleri ölçülebilir. Yeni planlanan sistemler için, yeni sistemin boyutlandırma alıştırması DBMS tarafında, I/O gereksinimlerinin kabaca fikirlerini de ver ver vermektedir. Emin değilseniz, sonunda bir Kavram Kanıtı yürütmeye ihtiyacınız vardır.
  3. DBMS sunucusunun SAPS gereksinimini, Farklı Azure vm türlerinin sağy olduğu SAPS ile karşılaştırın. Farklı Azure VM türlerinin SAPS'leri hakkında bilgiler SAP [Note]1928533. Veritabanı katmanı, dağıtımların büyük çoğunluğunda ölçeğini dışarı doğru ölçeklendiren bir SAP NetWeaver sistemi katmanı olduğu için öncelikle DBMS VM üzerinde odaklanmalısınız. Buna karşılık SAP uygulama katmanının ölçeği uztar. SAP tarafından desteklenen Azure VM türlerinden hiçbiri gerekli SAPS'yi sunamasa, planlanan SAP sisteminin iş yükü Azure'da çalıştırılamayabilirsiniz. Sistemi şirket içinde dağıtmanız veya sistemin iş yükü hacmini değiştirmeniz gerekir.
  4. Burada (Linux) ve burada (Windows)belgelenmiş olduğu gibi Azure, Standart depolama alanı veya sanal ağ kullanımına bakarak disk başına bağımsız bir IOPS Depolama Premium Depolama. VM türüne bağlı olarak, takılacak veri disklerinin sayısı değişir. Sonuç olarak, farklı VM türlerinin her biri ile elde edilebilir maksimum IOPS sayısını hesaplayabiliyoruz. Veritabanı dosya düzenine bağlı olarak, diskleri konuk işletim sistemi içinde tek bir birim olacak şekilde şerit haline ebilirsiniz. Ancak, dağıtılan bir SAP sisteminin geçerli IOPS hacmi Azure'ın en büyük VM türünün hesaplanmış sınırlarını aşarsa ve daha fazla bellekle telafi etme şansı yoksa SAP sisteminin iş yükü ciddi şekilde etkilanabilir. Böyle durumlarda, sistemi Azure'a dağıtmamanız gereken bir noktaya isabet edin.
  5. Özellikle 2 Katmanlı yapılandırmalarda şirket içinde dağıtılan SAP sistemlerinde, sistemin Azure'da 3 Katmanlı bir yapılandırmada yapılandırılması gerektirmektedir. Bu adımda, SAP uygulama katmanında ölçeği ölçeklendirilemayacak bir bileşen olup olmadığını ve farklı Azure VM türlerinin teklifi olan CPU ve bellek kaynaklarına sığıp uymaymayacaklarını denetlemeniz gerekir. Böyle bir bileşen varsa SAP sistemi ve iş yükü Azure'a dağıtılabilir. Ancak SAP uygulaması bileşenlerinin ölçeğini birden çok Azure VM'sine ölçeklendirebilir, sistem Azure'a dağıtılabilir.

DBMS ve SAP uygulama katmanı bileşenlerinin Azure VM'lerde çalıştırılabınıyor olması, yapılandırmanın aşağıdakilerle ilgili olarak tanımlanmalıdır:

  • Azure VM'lerinin sayısı
  • Tek tek bileşenler için VM türleri
  • Yeterli IOPS sağlamak için DBMS VM'sinde VHD sayısı

Azure varlıklarını yönetme

Azure portal

Bu Azure portal, Azure VM dağıtımlarını yönetmeye yardımcı olan üç arabirimden birisidir. Vm'leri görüntülerden dağıtma gibi temel yönetim görevleri, sanal Azure portal. Buna ek olarak, Depolama Hesapları, Sanal Ağlar ve diğer Azure bileşenlerinin oluşturulması, Azure portal işleyebilirsiniz. Ancak, VHD'leri şirket içinden Azure'a yükleme veya Azure'da VHD kopyalama gibi işlevler, üçüncü taraf araçları veya PowerShell ya da CLI aracılığıyla yönetim gerektiren görevlerdir.

Microsoft Azure portalı - Sanal Makineye genel bakış

Sanal Makine örneği için yönetim ve yapılandırma görevleri, sanal makine Azure portal.

Sanal Makine'yi yeniden başlatmanın ve kapatmanın yanı sıra, sanal makine örneği için görüntü hazırlama örneğini yakalamak ve Sanal Makine örneğinin boyutunu yapılandırmak üzere veri diskleri de iliştirebilir, ayırabilir ve oluşturabilirsiniz.

Bu Azure portal VM'leri ve diğer birçok Azure hizmetlerini dağıtmak ve yapılandırmak için temel işlevler sağlar. Ancak kullanılabilir işlevlerin hepsi Azure portal. Bu Azure portal aşağıdaki gibi görevleri gerçekleştirmek mümkün değildir:

  • VHD'leri Azure'a yükleme
  • VM'leri kopyalama

Microsoft Azure PowerShell cmdlet'leri aracılığıyla yönetim

Windows PowerShell, Azure'da çok sayıda sistem dağıtan müşteriler tarafından yaygın olarak benimsenmiş güçlü ve genişletilebilir bir çerçevedir. PowerShell cmdlet'leri masaüstü, dizüstü bilgisayar veya ayrılmış yönetim istasyonuna yüklemeden sonra, PowerShell cmdlet'leri uzaktan çalıştırabilirsiniz.

Azure PowerShell cmdlet'lerinin kullanımı için yerel masaüstü/dizüstü bilgisayarı etkinleştirme ve Azure abonelikleriyle kullanım için yapılandırma işlemi bu makalede açıklanmıştır.

Azure PowerShell cmdlet'lerini yükleme, güncelleştirme ve yapılandırma hakkında daha ayrıntılı adımlar, Yükleme Azure PowerShell bulunabilir. Şimdiye kadar müşteri deneyimi, PowerShell'in VM'leri dağıtmak ve VM dağıtımında özel adımlar oluşturmak için kesinlikle daha güçlü bir araç olduğu oldu. Azure'da SAP örnekleri çalıştıran tüm müşteriler, Azure portal'da yaptıkları yönetim görevlerini tamamlamak için PowerShell cmdlet'lerini kullanıyor ve hatta yalnızca Azure'daki dağıtımlarını yönetmek için PowerShell cmdlet'lerini kullanıyor. Azure'a özgü cmdlet'ler 2000'den fazla Windows ilgili cmdlet'lerle aynı adlandırma kuralını paylaştığından, Windows yöneticilerinin bu cmdlet'lerden faydalanmaları kolay bir görevdir.

Örnek için buraya bakın: https://blogs.technet.com/b/keithmayer/archive/2015/07/07/18-steps-for-end-to-end-iaas-provisioning-in-the-cloud-with-azure-resource-manager-arm-powershell-and-desired-state-configuration-dsc.aspx

SAP için Azure Uzantısı'nın dağıtımı (bu belgede SAP için Azure Uzantısı bölüme bakın) yalnızca PowerShell veya CLI aracılığıyla mümkündür. Bu nedenle, Azure'da SAP NetWeaver sistemi dağıtırken veya dağıtırken PowerShell veya CLI'yi ayarlamak ve yapılandırmak zorunludur.

Azure daha fazla işlev sağladığında, cmdlet'lerin güncelleştirilsini gerektiren yeni PowerShell cmdlet'leri eklenecektir. Bu nedenle, cmdlet'lerinin yeni bir sürümü için Azure İndirme sitesini ayda en az https://azure.microsoft.com/downloads/ bir kez denetlemeniz mantıklıdır. Yeni sürüm, eski sürümün üzerine yüklenir.

Azure ile ilgili PowerShell komutlarının genel listesi için buraya bakın: Azure PowerShell bakın.

Microsoft Azure CLI komutları aracılığıyla yönetim

Linux kullanan ve Azure kaynaklarını yönetmek isteyen müşteriler için PowerShell bir seçenek değildir. Microsoft alternatif olarak Azure CLI'sini sunar. Azure CLI, Azure Platformu ile çalışmak için bir dizi açık kaynak, platformlar arası komut sağlar. Azure CLI, hizmette bulunan işlevlerin büyük Azure portal.

Yükleme, yapılandırma ve Azure görevlerini gerçekleştirmek için CLI komutlarını kullanma hakkında bilgi için bkz.

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

Dağıtım planlamasının ilk adımı, SAP çalıştırmak için kullanılabilir VM'leri denetlemeYİSERİ'dir. İlk adım, zaman alan ancak en önemlisi, hangi TÜR SAP iş yükünü veya iş sürecini genel buluta dağıtmak için sınır koşullarının ne olduğuyla ilgili olarak şirketinizin uyumluluk ve güvenlik ekipleriyle çalışmak olabilir. Azure'a daha önce başka yazılımlar dağıtan bir şirket varsa bu işlem kolay olabilir. Yolculuğun başında daha fazla şirket varsa, sınır koşullarını, güvenlik koşullarını ve belirli SAP verilerini ve SAP iş işlemlerinin genel bulutta barındırnmalarını sağlayan daha büyük tartışmalar gerekebilir.

Yararlı bir yardım olarak, Microsoft'un sağldır olduğu uyumluluk tekliflerinin listesi için Microsoft uyumluluk tekliflerini işaret edin.

Beklemede olan veriler veya Azure hizmetlerinde diğer şifreleme verileri şifreleme gibi diğer endişe alanları, Azure şifrelemeye genel bakış konusunda belgelenir.

Planlamada projenin bu aşamasını hafife almayın. Yalnızca bu konu başlığıyla ilgili sözleşmeniz ve kurallarınız olduğunda, Azure'da dağıtarak ağ mimarisinin planlandır olduğu bir sonraki adıma gitebilirsiniz.

Azure'da SAP için VM'leri dağıtmanın farklı yolları

Bu bölümde, Azure 'da VM dağıtmanın farklı yollarını öğreneceksiniz. Ek hazırlık yordamları ve Azure 'da VHD 'lerin ve VM 'lerin işlenmesi bu bölümde ele alınmıştır.

SAP için VM dağıtımı

Microsoft Azure, vm 'leri ve ilişkili diskleri dağıtmanın birden çok yolunu sunar. Bu nedenle, VM 'lerin hazırlıkları dağıtım yöntemine bağlı olarak farklı olabileceğinden farklılıkları anlamak önemlidir. Genel olarak, aşağıdaki senaryolara göz atalım:

Bir VM 'yi Şirket içinden, genelleştirilmiş olmayan bir disk ile Azure 'a taşıma

Belirli bir SAP sistemini Şirket içinden Azure 'a taşımayı planlarsınız. Bu işlem, işletim sistemini, SAP Ikililerini ve DBMS ikililerini içeren VHD 'yi, DBMS 'nin veri ve günlük dosyalarıyla Azure 'a karşıya yükleyerek yapılabilir. Aşağıdaki senaryo #2aksine, Azure VM 'de ana bilgisayar adı, SAP SID 'SI ve SAP Kullanıcı hesaplarını şirket içi ortamda yapılandırıldıklarında saklayın. Bu nedenle, görüntüyü genelleştirerek gerekli değildir. Şirket içi hazırlama adımları ve genelleştirilmiş VM 'Ler ya da VHD 'lerin Azure 'a yüklenmesi için, BIR VM 'yi Şirket içinden bu belgenin Genelleştirilmiş olmayan bir disketiyle Azure 'a taşımaya yönelik bölüm hazırlama bölümüne bakın. Bölüm senaryosunu okuyun 3: Azure 'da böyle bir görüntüyü dağıtmanın ayrıntılı adımları için dağıtım KıLAVUZUNDA SAP Ile GENELLEŞTIRILMIŞ bir Azure VHD kullanarak bir VM 'Yi Şirket içinden taşıma .

Bu kılavuzda ayrıntılı olarak açıklanmayacak başka bir seçenek, SAP NetWeaver uygulama sunucularını ve SAP NetWeaver merkezi hizmetlerini Azure 'a çoğaltmak için Azure Site Recovery kullanmaktır. Veritabanı katmanı için Azure Site Recovery kullanmanız önerilmez ve HANA sistem çoğaltması gibi veritabanına özgü çoğaltma mekanizmalarını kullanın. Daha fazla bilgi için bkz. Şirket içi uygulamalar için olağanüstü durum kurtarma hakkında bilgi için bkz. bölüm koruma .

Müşteriye özgü bir görüntüyle VM dağıtma

İşletim sistemi veya DBMS sürümünüzün belirli düzeltme eki gereksinimleri nedeniyle, Azure Marketi 'ndeki sunulan görüntüler gereksinimlerinize uygun olmayabilir. Bu nedenle, daha sonra birkaç kez dağıtılabilecek özel işletim sistemi/DBMS VM görüntünüzü kullanarak bir VM oluşturmanız gerekebilir. Bu tür özel bir görüntüyü yineleme için hazırlamak üzere aşağıdaki öğelerin göz önünde bulundurulması gerekir:


Windows logo. Windows

daha fazla ayrıntı için, genelleştirilmiş bir Windows VHD Upload okuyun ve Azure 'da yeni vm 'ler oluşturmak için bunu kullanın Windows ayarları (Windows sıd ve ana bilgisayar adı gibi), sysprep komutu aracılığıyla şirket içi VM 'de soyutlanmalıdır/genelleştirilmelidir.

Linux logosu. Linux

Bir VHD 'yi Azure 'a yüklenecek şekilde hazırlamak için SUSE, Red Hatveya Oracle Linuxiçin bu makalelerde açıklanan adımları izleyin.


SAP içeriğini şirket içi sanal makinenize zaten yüklediyseniz (özellikle 2 katmanlı sistemler için), SAP yazılım sağlama Yöneticisi (SAP Note 1619720) tarafından desteklenen örnek yeniden adlandırma yordamı aracılığıyla Azure VM 'nin DAĞıTıMıNDAN sonra SAP sistem ayarlarını uyarlayabilirsiniz. Şirket içi hazırlama adımları ve genelleştirilmiş bir VM 'yi Azure 'a yüklemek için, BIR VM 'yi müşterilere özgü bir görüntüyle dağıtmak ve şirket içinden bir VHD 'yi bu belgenin Azure 'A yüklemek için bölüm hazırlığı konusuna bakın. Bölüm senaryosunu okuyun 2: Azure 'da böyle bir görüntüyü dağıtmaya yönelik ayrıntılı adımlar için dağıtım kılavuzunda bir VM 'yi özel bir görüntüyle dağıtma .

Azure Marketi 'Nden bir VM dağıtma

VM 'nizi dağıtmak için Azure Marketi 'nden bir Microsoft veya üçüncü taraf tarafından sağlanmış bir VM görüntüsü kullanmak istersiniz. VM 'nizi Azure 'da dağıttıktan sonra, SAP yazılımını ve/veya DBMS 'yi şirket içi bir ortamda yaptığınız gibi VM 'nizin içine yüklemek için aynı kılavuz ve araçları izleyin. Daha ayrıntılı dağıtım açıklaması için bkz. bölüm senaryosu 1: dağıtım KıLAVUZUNDA SAP Için Azure Marketi 'nden BIR VM dağıtma .

Azure için SAP ile VM 'Leri hazırlama

VM 'Leri Azure 'a yüklemeden önce VM 'Lerin ve VHD 'lerin belirli gereksinimleri karşıladıklarından emin olmanız gerekir. Kullanılan dağıtım yöntemine bağlı olarak küçük farklılıklar vardır.

Genelleştirilmiş olmayan bir diskle bir VM 'yi Şirket içinden Azure 'a taşımaya yönelik hazırlık

Ortak dağıtım yöntemi, şirket içi bir SAP sistemini çalıştıran mevcut bir VM 'yi Azure 'a taşımadır. VM 'deki bu VM ve SAP sisteminin aynı ana bilgisayar adını ve olasılıkla aynı SAP SID 'sini kullanarak Azure 'da çalışması gerekir. Bu durumda, VM 'nin Konuk işletim sistemi birden çok dağıtım için genelleştirilmemelidir. Şirket içi ağ Azure 'a genişletilmişse, aynı etki alanı hesapları, şirket içi önce kullanılan VM 'ler içinde de kullanılabilir.

Kendi Azure VM diskinizi hazırlarken gereksinimler şunlardır:

  • Başlangıçta işletim sistemini içeren VHD en büyük boyut olan 127 GB olabilir. Bu sınırlama Mart 2015 ' ün sonunda ortadan kaldırıldı. artık işletim sistemini içeren VHD, diğer Azure Depolama barındırılan VHD 'ler ile en fazla 1 TB olabilir.
  • Sabit VHD biçiminde olması gerekir. VHDx biçimindeki Dinamik VHD 'ler veya VHD 'ler henüz Azure 'da desteklenmiyor. VHD 'yi PowerShell Command, veya CLı ile karşıya yüklediğinizde Dinamik VHD 'ler statik VHD 'lere dönüştürülecek
  • VM 'ye bağlanan ve VM 'nin Azure 'da yeniden bağlanması gereken VHD 'ler, aynı zamanda bir sabit VHD biçiminde olmalıdır. Veri disklerinin boyut sınırları için Bu makaleyi okuyun. VHD 'yi PowerShell Command, veya CLı ile karşıya yüklediğinizde Dinamik VHD 'ler statik VHD 'lere dönüştürülecek
  • Yönetim ayrıcalıklarına sahip başka bir yerel hesap ekleyin, bu, Microsoft desteği tarafından kullanılabilen veya VM dağıtılmadan ve daha uygun kullanıcıların kullanılabilmesi için içinde çalışacağı hizmet ve uygulamaların bağlamı olarak atanabileceği bir yerel hesap ekleyin.
  • Belirli dağıtım senaryosu için gerekli olabilecek diğer yerel hesapları ekleyin.

Windows logo. Windows

Bu senaryoda VM 'yi karşıya yüklemek ve Azure 'a dağıtmak için VM 'nin Genelleştirme (Sysprep) gerekmez. D:\ sürücüsünün olduğundan emin olun kullanılmaz. Bu belgedeki ekli diskler için otomatik bağlama ayarı bölümünde açıklandığı gibi ekli diskler için disk otomatik bağlama ayarlayın.

Linux logosu. Linux

Bu senaryoda VM 'yi karşıya yüklemek ve Azure 'a dağıtmak için VM 'nin Genelleştirme (waagent-deprovision) gerekmez. /Mnt/Resource ' ın kullanılmadığından ve tüm disklerin UUID aracılığıyla bağlandığından emin olun. İşletim sistemi diski için, önyükleme yükleyicisi girişinin UUID tabanlı bağlama de yansıttığından emin olun.


SAP için müşteriye özgü bir görüntüyle VM dağıtmaya hazırlanma

genelleştirilmiş bir işletim sistemi içeren VHD dosyaları, Azure Depolama hesapları veya yönetilen Disk görüntüleri olarak kapsayıcılar içinde depolanır. Bu tür bir görüntüden yeni bir VM 'yi, Bölüm Senaryo 2: Dağıtım Kılavuzu'nun SAP için özel bır görüntüyle bir VM dağıtma bölümünde açıklandığı gibi, dağıtım şablonu dosyalarınızda kaynak olarak veya yönetilen disk görüntüsüne başvurarak dağıtabilirsiniz.

Kendi Azure VM görüntünüzü hazırlarken gereksinimler şunlardır:

  • Başlangıçta işletim sistemini içeren VHD en büyük boyut olan 127 GB olabilir. Bu sınırlama Mart 2015 ' ün sonunda ortadan kaldırıldı. artık işletim sistemini içeren VHD, diğer Azure Depolama barındırılan VHD 'ler ile en fazla 1 TB olabilir.
  • Sabit VHD biçiminde olması gerekir. VHDx biçimindeki Dinamik VHD 'ler veya VHD 'ler henüz Azure 'da desteklenmiyor. VHD 'yi PowerShell Command, veya CLı ile karşıya yüklediğinizde Dinamik VHD 'ler statik VHD 'lere dönüştürülecek
  • VM 'ye bağlanan ve VM 'nin Azure 'da yeniden bağlanması gereken VHD 'ler, aynı zamanda bir sabit VHD biçiminde olmalıdır. Veri disklerinin boyut sınırları için Bu makaleyi okuyun. VHD 'yi PowerShell Command, veya CLı ile karşıya yüklediğinizde Dinamik VHD 'ler statik VHD 'lere dönüştürülecek
  • Belirli dağıtım senaryosu için gerekli olabilecek diğer yerel hesapları ekleyin.
  • Görüntüde bir SAP NetWeaver yüklemesi varsa ve Azure dağıtımı noktasındaki asıl adından ana bilgisayar adının yeniden adlandırılması büyük olasılıkla, SAP yazılım sağlama Yöneticisi DVD 'sinin en son sürümlerini şablona kopyalamanız önerilir. Bu, değiştirilen ana bilgisayar adını uyarlamak ve/veya yeni bir kopya başlatıldıktan hemen sonra dağıtılan VM görüntüsü içindeki SAP sisteminin SID 'sini değiştirmek için SAP tarafından girilen yeniden adlandırma işlevselliğini kolayca kullanmanıza imkan sağlar.

Windows logo. Windows

D:\ sürücüsünün olduğundan emin olun , bu belgedeki ekli diskler için otomatik bağlama ayarı bölümünde açıklandığı gibi ekli diskler için disk otomatik bağlama ayarla kullanılmaz.

Linux logosu. Linux

/Mnt/Resource ' ın kullanılmadığından ve tüm disklerin UUID aracılığıyla bağlandığından emin olun. İşletim sistemi diski için, önyükleme yükleyicisi girişinin UUID tabanlı bağlama de yansıttığından emin olun.


  • SAP GUI (Yönetim ve kurulum amaçları için) bu tür bir şablonda önceden yüklenmiş olabilir.
  • Bu yazılım VM 'nin yeniden adlandırılmasına çalışabilecek sürece VM 'Leri şirketler arası senaryolarda başarıyla çalıştırmak için gereken diğer yazılımlar yüklenebilir.

VM 'nin genel olması yeterince hazırlanmışsa ve son olarak, hedeflenen Azure dağıtım senaryosunda hesap/kullanıcılardan bağımsız olarak, bu tür bir görüntüyü genelleştirmeye yönelik son hazırlık adımı yürütülür.

VM 'yi Genelleştirme

Windows logo. Windows

Son adım, bir yönetici hesabıyla bir VM 'de oturum açmak için kullanılır. yönetici olarak bir Windows komut penceresi açın. %Windir%\Windows\System32\Sysprep adresine gidin ve sysprep.exe yürütün. Küçük bir pencere görünür. Genelleştir seçeneğini denetlemek önemlidir (varsayılan olarak işaretli değildir) ve varsayılan ' reboot ' olan ' reboot ' olan kapalı seçeneğini ' kapalı ' olarak değiştirir. Bu yordam, Sysprep işleminin bir VM 'nin Konuk işletim sisteminde şirket içinde yürütüldüğünü varsayar. Yordamı Azure 'da zaten çalışan bir VM ile gerçekleştirmek istiyorsanız, Bu makaledeaçıklanan adımları izleyin.

Linux logosu. Linux

Kaynak Yöneticisi şablonu olarak kullanmak üzere Linux sanal makinesi yakalama


VM 'Leri ve VHD 'Leri Şirket içinden Azure 'a aktarma

VM görüntülerini ve disklerini Azure 'a yükleme Azure portal aracılığıyla mümkün olmadığından, Azure PowerShell cmdlet 'lerini veya clı 'yi kullanmanız gerekir. ' AzCopy ' aracının kullanılması başka bir olasılık. Araç, VHD 'leri şirket içi ve Azure arasında (her iki yönde) kopyalayabilir. Ayrıca, VHD 'leri Azure bölgeleri arasında kopyalayabilir. AzCopy 'in indirilmesi ve kullanımı için Bu belgelere başvurun.

Üçüncü bir alternatif, çeşitli üçüncü taraf GUI odaklı araçları kullanmaktır. Ancak, bu araçların Azure sayfa Bloblarını desteklemesini sağlayın. Azure Sayfa Blobu deposu kullanılması gerekir. bu farklar, blok bloblarını, ekleme bloblarını ve sayfa Bloblarını anlamabölümünde açıklanmıştır. Ayrıca, Azure tarafından sunulan araçlar, karşıya yüklenmesi gereken VM 'Leri ve VHD 'Leri sıkıştırmak için etkilidir. Bu, sıkıştırmanın içindeki bu verimlilik karşıya yükleme süresini azalttığından (aynı zamanda şirket içi tesis ve hedeflenen Azure dağıtım bölgesinden internet 'e karşıya yükleme bağlantısına bağlı olarak farklılık gösterir) önemlidir. Avrupa konumundan ABD tabanlı Azure veri merkezlerine bir VM veya VHD 'yi karşıya yüklemek, Avrupa Azure veri merkezlerine aynı VM 'Leri/VHD 'Leri karşıya yüklemeden daha uzun sürer.

Şirket içinden Azure 'a VHD yükleme

Mevcut bir VM veya VHD 'yi, şirket içi ağdan, bu belgenin Genelleştirilmiş olmayan bir disketiyle BIR VM 'yi şirket Içinden Azure 'a taşımaya yönelik bölüm hazırlığı bölümünde listelenen gereksinimlere uyması gerekir.

Bu tür bir VM 'nin genelleştirilmesi gerekmez ve şirket içi tarafında kapatıldıktan sonra sahip olduğu durum ve şekle yüklenebilir. Aynı işlem, herhangi bir işletim sistemi içermeyen ek VHD 'ler için de geçerlidir.

Bir VHD 'YI karşıya yükleme ve bir Azure diski yapma

Bu durumda, bir VHD 'yi bir işletim sistemi ile veya olmadan karşıya yüklemek ve bir sanal makineye bir veri diski olarak bağlamak veya işletim sistemi diski olarak kullanmak istiyoruz. Bu, çok adımlı bir işlemdir

PowerShell

  • Bağlan-azaccount ile aboneliğinizde oturum açın
  • Set-azcontext ve Parameter SubscriptionID veya subscriptionName parametreleri ile bağlamınızın aboneliğini ayarlayın-bkz. set-azcontext
  • Azure Depolama hesabına add-azvhd ile VHD 'yi Upload-bkz. add-azvhd
  • Seçim VHD 'den New-azdisk ile yönetilen bir disk oluşturma-Bkz. New-azdisk
  • Yeni bir VM yapılandırmasının işletim sistemi diskini, set-azvmosdisk ile VHD veya yönetilen diske ayarlama-Bkz. set-AzVMOSDisk
  • New-azvm ile VM yapılandırmadan yenı bir VM oluşturma-Bkz. New-azvm
  • Add-azvmdatadisk ile yenı bir VM 'ye veri diski ekleme-Bkz. Add-AzVMDataDisk

Azure CLI

  • Az Login ile aboneliğinizde oturum açın
  • Az Account set- <subscription name or id > -Subscription ile aboneliğinizi seçin
  • VHD 'yi az storage blob Upload ile Upload-bkz. azure clı ile azure Depolama kullanma.
  • Seçim VHD 'den bir yönetilen disk oluşturun az disk Create -See az disk.
  • Karşıya yüklenen VHD veya yönetilen diski işletim sistemi diski olarak belirterek az VM Create ve Parameter --Attach-OS-disk olan yeni bir VM oluşturun
  • Az VM disk Attach ve Parameter ile yenı bir VM 'ye veri diski ekleme --Yeni

Şablon

  • VHD 'yi PowerShell veya Azure clı ile Upload
  • Seçim PowerShell, Azure CLı veya Azure portal ile VHD 'den yönetilen disk oluşturma
  • VM 'yi Bu örnek JSON şablonunda gösterildiği gıbı, VHD 'ye başvuran bir JSON şablonuyla veya Bu örnek JSON şablonundagösterildiği gibi yönetilen diskleri kullanarak dağıtın.

VM görüntüsü dağıtımı

Mevcut bir VM 'yi veya VHD 'yi, şirket içi ağdan yüklemek için, bir VM veya VHD 'nin bu belgenin SAP için müşteriye özgü bir görüntüyle BIR VM dağıtmaya yönelik bölüm hazırlığı bölümünde listelenen gereksinimleri karşılaması gerekir.

Azure CLI

Şablon

VHD 'leri veya yönetilen diskleri şirket içine indirme

Hizmet olarak Azure altyapısı, yalnızca VHD 'leri ve SAP sistemlerini karşıya yükleyebilecekler için tek yönlü bir cadde değildir. SAP sistemlerini Azure 'dan şirket içi dünyaya geri taşıyabilirsiniz.

İndirme sırasında VHD 'ler veya yönetilen diskler etkin olamaz. VM 'lere bağlanan diskler indirilirken bile, sanal makinenin kapatılması ve serbest bırakılmasının olması gerekir. Yalnızca veritabanı içeriğini indirmek istiyorsanız, bu durumda, şirket içinde yeni bir sistem kurmak için kullanılması gerekir ve indirme sırasında ve yeni sistemin kurulumu sırasında Azure 'daki sistemin hala çalışır durumda olduğu kabul edilebilir ise, bir diske sıkıştırılmış bir veritabanı yedeklemesi gerçekleştirerek ve IŞLETIM sistemini indirmek yerine yalnızca o diski indirebilirsiniz. Temel VM.

PowerShell

  • Yönetilen disk indiriliyor, önce yönetilen diskin temel blobuna erişmeniz gerekir. Ardından, temel alınan blobu yeni bir depolama hesabına kopyalayabilir ve blobu bu depolama hesabından indirebilirsiniz.

    $access = Grant-AzDiskAccess -ResourceGroupName <resource group> -DiskName <disk name> -Access Read -DurationInSecond 3600
    $key = (Get-AzStorageAccountKey -ResourceGroupName <resource group> -Name <storage account name>)[0].Value
    $destContext = (New-AzStorageContext -StorageAccountName <storage account name -StorageAccountKey $key)
    Start-AzStorageBlobCopy -AbsoluteUri $access.AccessSAS -DestContainer <container name> -DestBlob <blob name> -DestContext $destContext
    # Wait for blob copy to finish
    Get-AzStorageBlobCopyState -Container <container name> -Blob <blob name> -Context $destContext
    Save-AzVhd -SourceUri <blob in new storage account> -LocalFilePath <local file path> -StorageKey $key
    # Wait for download to finish
    Revoke-AzDiskAccess -ResourceGroupName <resource group> -DiskName <disk name>
    
  • Bir VHD 'yi indirme SAP sistemi durdurulduğunda ve VM kapatıldıktan sonra, Save-AzVhd VHD disklerini şirket içi dünyaya geri yüklemek için şirket içi hedefteki PowerShell cmdlet 'ini kullanabilirsiniz. bunu yapmak için, Azure portal ' depolama bölümünde bulabileceğiniz vhd 'nin URL 'sine ihtiyacınız vardır (Depolama hesabına ve vhd 'nin oluşturulduğu depolama kapsayıcısına gitmeniz gerekir) ve vhd 'nin nereye kopyalanıp kopyalanmayacağını bilmeniz gerekir.

    Ardından, kaynak URI 'sini indirmek üzere VHD 'nin URL 'si olarak ve LocalFilePath öğesini VHD 'nin fiziksel konumu (adı dahil) olarak tanımlayarak komutunu kullanabilirsiniz. Komut şu şekilde görünebilir:

    Save-AzVhd -ResourceGroupName <resource group name of storage account> -SourceUri http://<storage account name>.blob.core.windows.net/<container name>/sapidedata.vhd -LocalFilePath E:\Azure_downloads\sapidesdata.vhd
    

    Save-AzVhd cmdlet 'i hakkında daha fazla bilgi için bkz. Save-AzVhd.

Azure CLI

  • Yönetilen disk indiriliyor, önce yönetilen diskin temel blobuna erişmeniz gerekir. Ardından, temel alınan blobu yeni bir depolama hesabına kopyalayabilir ve blobu bu depolama hesabından indirebilirsiniz.

    az disk grant-access --ids "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" --duration-in-seconds 3600
    az storage blob download --sas-token "<sas token>" --account-name <account name> --container-name <container name> --name <blob name> --file <local file>
    az disk revoke-access --ids "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>"
    
  • Bir VHD 'YI indirme SAP sistemi durdurulduğunda ve VM kapatıldıktan sonra, _azure storage blob download_ VHD disklerini şirket içi dünyaya geri yüklemek için şirket içi hedefte Azure CLI komutunu kullanabilirsiniz. bunu yapmak için, Azure portal ' Depolama bölümünde (Depolama hesabına ve vhd 'nin oluşturulduğu depolama kapsayıcısına gitmeniz gerekir) vhd 'nin adı ve kapsayıcısına ihtiyacınız vardır. bu, vhd 'nin ' ye kopyalanması gereken yeri bilmeniz gerekir.

    Ardından, indirilecek VHD 'nin kapsayıcısını ve kapsayıcısını ve hedefi VHD 'nin fiziksel hedef konumu (adı dahil) olarak tanımlayarak komutunu kullanabilirsiniz. Komut şu şekilde görünebilir:

    az storage blob download --name <name of the VHD to download> --container-name <container of the VHD to download> --account-name <storage account name of the VHD to download> --account-key <storage account key> --file <destination of the VHD to download>
    

Azure 'da VM 'Leri ve diskleri aktarma

Azure 'da SAP sistemlerini kopyalama

SAP sistemi veya SAP uygulama katmanını destekleyen adanmış bir DBMS sunucusu, büyük olasılıkla, ikili dosyaları içeren işletim sistemini veya SAP veritabanının veri ve günlük dosyalarını içeren birkaç diskten oluşur. Diskleri kopyalamanın ve Azure işlevselliğinin yerel bir diske kaydedilmesi için Azure işlevselliği, birden çok diskin tutarlı bir şekilde anlık görüntüsünü veren bir eşitleme mekanizmasına sahip değildir. Bu nedenle, aynı VM 'ye karşı bağlansalar bile kopyalanmış veya kaydedilmiş disklerin durumu farklı olabilir. Diğer bir deyişle farklı disklerde farklı veri ve günlük dosyası (ler) dahil olmak üzere, sonundaki veritabanı tutarsız olur.

Sonuç: bir SAP sistem yapılandırmasının parçası olan diskleri kopyalamak veya kaydetmek için SAP sistemini durdurmanız ve ayrıca dağıtılan VM 'yi kapatmanız gerekir. Yalnızca Azure 'da veya şirket içinde SAP sisteminin bir kopyasını oluşturmak için disk kümesini kopyalayabilir veya indirebilirsiniz.

veri diskleri, bir Azure Depolama hesabında VHD dosyaları olarak depolanabilir ve doğrudan bir sanal makineye bağlanabilir veya görüntü olarak kullanılabilir. Bu durumda, VHD sanal makineye iliştirilmeden önce başka bir konuma kopyalanır. Azure 'da VHD dosyasının tam adı Azure içinde benzersiz olmalıdır. Daha önce belirtildiği gibi, adı şu şekilde görünen üç bölümden oluşan bir ad türü olmalıdır:

http(s)://<storage account name>.blob.core.windows.net/<container name>/<vhd name>

Veri diskleri de yönetilen diskler olabilir. Bu durumda, yönetilen disk, sanal makineye iliştirilmeden önce yeni bir yönetilen disk oluşturmak için kullanılır. Yönetilen diskin adı bir kaynak grubu içinde benzersiz olmalıdır.

PowerShell

Azure PowerShell cmdlet 'lerini, bu makaledegösterildiği gibi bir VHD 'yi kopyalamak için kullanabilirsiniz. Yeni bir Yönetilen Disk oluşturmak için, aşağıdaki New-AzDiskConfig New-AzDisk yönetilen diskleri ve diskleri kullanın.

$config = New-AzDiskConfig -CreateOption Copy -SourceUri "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" -Location <location>
New-AzDisk -ResourceGroupName <resource group name> -DiskName <disk name> -Disk $config
Azure CLI

VHD'leri kopyalamak için Azure CLI'sini kullanabilirsiniz. Yeni bir Yönetilen Disk oluşturmak için aşağıdaki örnekte gösterildiği gibi az disk create kullanın.

az disk create --source "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/disks/<disk name>" --name <disk name> --resource-group <resource group name> --location <location>
Azure Depolama araçları

Professional Explorer'ların Depolama sürümlerine buradan bakabilirsiniz:

Depolama hesabı içindeki VHD'nin kopyalanması yalnızca birkaç saniye sürer (san donanımının yazma sırasında yavaş kopyalama ve kopyalama ile anlık görüntüler oluşturması gibi). VHD dosyasının bir kopyasına sahip olduktan sonra, bunu bir sanal makineye iliştirebilirsiniz veya VHD'nin kopyalarını sanal makinelere eklemek için bir görüntü olarak kullanabilirsiniz.

PowerShell
# attach a vhd to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name newdatadisk -VhdUri <path to vhd> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption attach
$vm | Update-AzVM

# attach a managed disk to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name newdatadisk -ManagedDiskId <managed disk id> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption attach
$vm | Update-AzVM

# attach a copy of the vhd to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$vm = Add-AzVMDataDisk -VM $vm -Name <disk name> -VhdUri <new path of vhd> -SourceImageUri <path to image vhd> -Caching <caching option> -DiskSizeInGB $null -Lun <lun, for example 0> -CreateOption fromImage
$vm | Update-AzVM

# attach a copy of the managed disk to a vm
$vm = Get-AzVM -ResourceGroupName <resource group name> -Name <vm name>
$diskConfig = New-AzDiskConfig -Location $vm.Location -CreateOption Copy -SourceUri <source managed disk id>
$disk = New-AzDisk -DiskName <disk name> -Disk $diskConfig -ResourceGroupName <resource group name>
$vm = Add-AzVMDataDisk -VM $vm -Caching <caching option> -Lun <lun, for example 0> -CreateOption attach -ManagedDiskId $disk.Id
$vm | Update-AzVM
Azure CLI

# attach a vhd to a vm
az vm unmanaged-disk attach --resource-group <resource group name> --vm-name <vm name> --vhd-uri <path to vhd>

# attach a managed disk to a vm
az vm disk attach --resource-group <resource group name> --vm-name <vm name> --disk <managed disk id>

# attach a copy of the vhd to a vm
# this scenario is currently not possible with Azure CLI. A workaround is to manually copy the vhd to the destination.

# attach a copy of a managed disk to a vm
az disk create --name <new disk name> --resource-group <resource group name> --location <location of target virtual machine> --source <source managed disk id>
az vm disk attach --disk <new disk name or managed disk id> --resource-group <resource group name> --vm-name <vm name> --caching <caching option> --lun <lun, for example 0>

Azure Depolama Hesapları arasında diskleri kopyalama

Bu görev, çalışma Azure portal. Cmdlet'Azure PowerShell, Azure CLI veya üçüncü taraf depolama tarayıcısını kullanabilirsiniz. PowerShell cmdlet'leri veya CLI komutları blobları oluşturabilir ve yönetebilir. Bu komutlar blobları Depolama Hesapları arasında ve Azure aboneliği içindeki bölgeler arasında zaman uyumsuz olarak kopyalama olanağını içerir.

PowerShell

VhD'leri abonelikler arasında da kopyaabilirsiniz. Daha fazla bilgi için bu makaleyi okuyun.

PowerShell cmdlet mantığının temel akışı şöyledir:

  • New-AzStorageContext ile kaynak depolama hesabı için depolama hesabı bağlamı oluşturma - bkz. New-AzStorageContext
  • New-AzStorageContext ile hedef depolama hesabı için depolama hesabı bağlamı oluşturma - bkz. New-AzStorageContext
  • Kopyalamayı ile başlatma
Start-AzStorageBlobCopy -SrcBlob <source blob name> -SrcContainer <source container name> -SrcContext <variable containing context of source storage account> -DestBlob <target blob name> -DestContainer <target container name> -DestContext <variable containing context of target storage account>
  • ile bir döngüde kopyanın durumunu denetleme
Get-AzStorageBlobCopyState -Blob <target blob name> -Container <target container name> -Context <variable containing context of target storage account>
  • Yeni VHD'i yukarıda açıklandığı gibi bir sanal makineye iliştirin.

Örnekler için bu makaleye bakın.

Azure CLI
  • Kopyalamayı ile başlatma
az storage blob copy start --source-blob <source blob name> --source-container <source container name> --source-account-name <source storage account name> --source-account-key <source storage account key> --destination-container <target container name> --destination-blob <target blob name> --account-name <target storage account name> --account-key <target storage account name>
  • Kopyalamanın şu döngüde olup ola bir durumda olduğunu kontrol edin:
az storage blob show --name <target blob name> --container <target container name> --account-name <target storage account name> --account-key <target storage account name>
  • Yeni VHD'i yukarıda açıklandığı gibi bir sanal makineye iliştirin.

Disk İşleme

SAP dağıtımları için VM/disk yapısı

İdeal olarak, bir VM'nin ve ilişkili disklerin yapısının işlenmesi basit bir işlemdir. Şirket içi yüklemelerde müşteriler, sunucu yüklemesini yapılandırmanın birçok yolu geliştirdi.

  • DbMS ve/veya SAP'nin işletim sistemi ve tüm ikililerini içeren bir temel disk. Mart 2015'ten itibaren bu diskin boyutu 127 GB ile sınırlandıran önceki kısıtlamalar yerine 1 TB'a kadar olabilir.
  • SAP veritabanının DBMS günlük dosyasını ve DBMS geçici depolama alanı günlük dosyasını içeren bir veya birden çok disk (DBMS bunu destekliyorsa). Veritabanı günlüğü IOPS gereksinimleri yüksekse, gereken IOPS birimine ulaşmak için birden çok diske şerit oluşturmanız gerekir.
  • SAP veritabanının bir veya iki veritabanı dosyası ve DBMS geçici veri dosyalarını içeren bir dizi disk (DBMS bunu destekliyorsa).

SAP için Azure IaaS VM'sinde Başvuru Yapılandırması


Windows logo. Windows

Birçok müşteriyle sap ve DBMS ikilileri gibi yapılandırmaların c:\ üzerinde yüklü olmadığını gördük işletim sistemi yüklü olan sürücü. Bunun çeşitli nedenleri vardı ama köke geri dönecek olsak genellikle sürücülerin küçük olması ve işletim sistemi yükseltmelerinin 10-15 yıl önce ek alana ihtiyacı vardı. Her iki durum da artık çok sık uygulanmıyor. Bugün c:\ sürücü, büyük birim diskleri veya VM'ler üzerinde eşlenmiş olabilir. Dağıtımları yapılarında basit tutmak için Azure'da SAP NetWeaver sistemleri için aşağıdaki dağıtım desenini izlemeniz önerilir

İşletim Windows disk belleği dosyası D: sürücüsü (kalıcı olmayan disk) üzerinde olmalıdır

Linux logosu. Linux

Linux swapfile dosyasını bu makalede açıklandığı gibi Linux'ta /mnt /mnt/resource altına yer değiştirin. Değiştirme dosyası Linux Aracısı /etc/waagent.conf yapılandırma dosyasında yalıtabilirsiniz. Aşağıdaki ayarları ekleyin veya değiştirin:

ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=30720

Değişiklikleri etkinleştirmek için linux aracıyı ile yeniden başlatmanız gerekir

sudo service waagent restart

Önerilen takas dosyası 1597355 daha fazla ayrıntı için SAP Not Defteri makalelerini okuyun


DBMS veri dosyaları için kullanılan disk sayısı ve bu disklerin barındır Depolama Azure depolama alanı türü, IOPS gereksinimlerine ve gereken gecikme süresine göre belirlenecektir. Tam kotalar bu makalede (Linux) ve bu makalede (Windows) açıklanmıştır.

Son iki yıl içinde SAP dağıtımları deneyimi bize şu şekilde özetlenebilir bazı dersler verdi:

  • Mevcut müşteri sistemlerinde SAP veritabanılarını temsil eden farklı boyutlu veri dosyaları olabileceği için farklı veri dosyalarına IOPS trafiği her zaman aynı değildir. Sonuç olarak, birden çok disk üzerinde RAID yapılandırması kullanarak luN'ların bu disklerden çıkar olduğu veri dosyalarını daha iyi bir şekilde kullanabilirsiniz. Özellikle Azure Standard Depolama IOPS oranının DBMS işlem günlüğünde tek disk kotasına isabet eden durumlar vardı. Bu tür senaryolarda, Premium Depolama kullanılması veya alternatif olarak yazılım şeridiyle birden çok Standart Depolama diskin toplaması önerilir.

Windows logo. Windows

Linux logosu. Linux


  • Premium Depolama, özellikle de kritik işlem günlüğü yazma işlemleri için önemli ölçüde daha iyi performans gösteriyor. Performans gibi üretim teslimi beklenen SAP senaryolarında, Azure VM-Series'den yararlanan Premium Depolama.

Işletim sistemi içeren diskin ve bizim önerimiz gibi SAP ile veritabanının (temel VM) ikililerinin de artık 127 GB ile sınırlı olmadığını unutmayın. Artık boyutu 1 TB'a kadar olabilir. Bu, sap toplu iş günlükleri gibi gerekli tüm dosyaları tutmak için yeterli alan olacaktır.

DbMS VM'leri için daha fazla öneri ve daha fazla ayrıntı için DBMS Dağıtım Kılavuzu'na bakın

Disk İşleme

Çoğu senaryoda, SAP veritabanını VM'ye dağıtmak için ek diskler oluşturmanız gerekir. Bu belgenin SAP dağıtımları için VM/disk yapısı bölümünde disk sayısıyla ilgili önemli noktalardan söz ettik. Bu Azure portal, temel VM dağıtıldıktan sonra diskleri eklemeye ve ayırmaya olanak sağlar. VM çalışır ve çalışır olduğunda ve durdurulurken diskler ekli/ayrılabilir. Disk ekliyken, Azure portal boş bir disk veya mevcut bir disk eklemeyi sunar. Bu disk şu anda başka bir VM'ye bağlı değildir.

Not: Diskler herhangi bir zamanda yalnızca bir VM'ye iliştirilmiş olabilir.

Azure Standard Depolama ile disk ekleme/ayırma

Yeni bir sanal makinenin dağıtımı sırasında, sanal makineleri kullanmak mı yoksa disklerinizi Azure Yönetilen Diskler hesaplarına mı Depolama karar veebilirsiniz. Premium Depolama kullanmak Yönetilen Diskler.

Ardından, yeni ve boş bir disk mi oluşturmak istediğinize yoksa daha önce karşıya yüklenen ve şimdi VM'ye bağlı olması gereken var olan bir diski seçmek mi istediğinize karar verebilirsiniz.

ÖNEMLİ: Azure Standard Önbelleğe Alma ile Konak Depolama. Konak Önbelleği tercihini varsayılan NONE ayarında bırakmanız gerekir. Azure Premium Depolama veritabanı veri dosyalarında genellikle tipik Önbelleğe Alma gibi okundu ise Okuma ve Okuma özelliğini etkinleştirmeniz gerekir. Veritabanı işlem günlüğü dosyası için önbelleğe alma önerilmez.


Windows logo. Windows

Veri diskini Azure portal

Diskler bağlı ise, vm'de oturum açıp Disk Yöneticisi'ni Windows gerekir. Eklenen diskler için otomatik olarak bağlanmayı ayarlama bölümünde önerildiğinde otomatik bağlantı etkinleştirilmemişse, yeni eklenen birimin çevrimiçi ortamda alınması ve başlatılması gerekir.

Linux logosu. Linux

Diskler eklenmişse, VM'de oturum açmanız ve bu makalede açıklandığı gibi diskleri başlatmanız gerekir


Yeni disk boş bir diskse diski de biçimlendirmelisiniz. Biçimlendirme için, özellikle DBMS verileri ve günlük dosyaları için DBMS'nin çıplak dağıtımları için öneriler geçerlidir.

Azure Depolama hesabı, I/O birimi, IOPS ve veri hacmi açısından sonsuz kaynak sağlamaz. Genellikle DBMS VM'leri bu durumdan en çok etkilenir. Azure Depolama hesabı hacminin sınırında kalmak için birkaç yüksek g/ç birimi sanal makinesi varsa, her VM için ayrı bir Depolama hesabı kullanmak en iyi yöntem olabilir. aksi takdirde, her bir Depolama hesabının sınırına vurmadan bu vm 'leri farklı Depolama hesapları arasında nasıl dengeleyebilirsiniz. Daha fazla ayrıntı, DBMS dağıtım kılavuzundaele alınmıştır. Ayrıca, saf SAP uygulama sunucusu VM 'Leri veya diğer VM 'ler için bu sınırlamaları aklınızda tutmanız gerekir. bu durum sonunda ek VHD 'Ler gerektirebilir. Yönetilen disk kullanıyorsanız bu kısıtlamalar uygulanmaz. Premium Depolama kullanmayı planlıyorsanız, yönetilen Disk kullanmanızı öneririz.

Depolama hesapları için uygun olan başka bir konu, bir Depolama hesabındaki vhd 'lerin coğrafi olarak çoğaltılma sahip olup olmadığı. coğrafi çoğaltma, VM düzeyinde değil Depolama hesap düzeyinde etkin veya devre dışı bırakıldı. coğrafi çoğaltma etkinse, Depolama hesabındaki vhd 'ler aynı bölgedeki başka bir Azure veri merkezine çoğaltılır. Buna karar vermeden önce, aşağıdaki kısıtlamayı düşünmeniz gerekir:

Azure coğrafi çoğaltma, bir VM 'deki her VHD üzerinde yerel olarak çalışarak, bir VM 'de birden çok VHD üzerinde g/ç 'yi kronolojik sırada çoğaltmaz. Bu nedenle, temel VM 'yi temsil eden VHD 'nin yanı sıra VM 'ye bağlı ek VHD 'ler birbirinden bağımsız olarak çoğaltılır. Bu, farklı VHD 'lerde yapılan değişiklikler arasında eşitleme olmadığı anlamına gelir. G/ç 'nin yazıldığı sırada bağımsız olarak çoğaltılacağı, coğrafi çoğaltmanın, veritabanlarının veritabanları birden çok VHD üzerinde dağıtılan veritabanı sunucuları için değer olmadığı anlamına gelir. DBMS 'ye ek olarak, işlemlerin farklı VHD 'lerde veri yazacağı veya işlediği ve değişikliklerin sırasını korumak için önemli olduğu diğer uygulamalar da olabilir. Bu bir gereksinimle, Azure 'da coğrafi çoğaltma etkinleştirilmemelidir. bir sanal makine kümesi için coğrafi çoğaltma isteyip istememe ya da tercih etmeksizin, ancak başka bir küme için, sanal makineleri ve ilgili vhd 'leri, coğrafi çoğaltma etkin veya devre dışı olan farklı Depolama hesaplara zaten kategorilere ayırabilirsiniz.

İliştirilmiş diskler için otomatik bağlama ayarlama


Windows logo. Windows

Kendi görüntülerinden veya disklerden oluşturulan VM 'Ler için otomatik bağlama parametresini denetlemeniz ve muhtemelen ayarlamanız gerekir. Bu parametrenin ayarlanması, Azure 'daki yeniden başlatma veya yeniden dağıtım sonrasında bağlı/bağlı sürücüleri otomatik olarak yeniden bağlamak için VM 'nin izin verir. Parametresi, Azure Market 'te Microsoft tarafından sunulan görüntüler için ayarlanır.

Otomatik bağlama ayarlamak için aşağıdaki diskpart.exe komut satırı yürütülebilir dosyasının belgelerini denetleyin:

Windows komut satırı penceresi yönetici olarak açılmalıdır.

diskler iliştirilmişse, Windows Disk yöneticisini açmak için VM 'de oturum açmanız gerekir. Otomatik bağlama, eklenen diskler için otomatik bağlamabölümünde önerilen şekilde etkinleştirilmemişse, yeni eklenen birimin >çevrimiçi olarak alınması ve başlatılması gerekir.

Linux logosu. Linux

Bu makaledeaçıklandığı gibi yeni eklenen boş diski başlatmalısınız. Ayrıca,/etc/fstabna yeni diskler eklemeniz gerekir.


Son dağıtım

Son dağıtım ve tam adımlar için, özellikle SAP için Azure uzantısının dağıtımı, dağıtım kılavuzunabakın.

Azure VM 'Leri içinde çalışan SAP sistemlerine erişme

SAP GUI 'yi kullanarak genel İnternet üzerinden bu SAP sistemlerine bağlanmak istediğiniz senaryolar için aşağıdaki yordamların uygulanması gerekir.

Bu belgede daha sonra, şirket içi sistemler ve Azure sistemleri arasında siteden siteye bağlantı (VPN tüneli) veya Azure ExpressRoute bağlantısı olan şirket içi dağıtımlardaki SAP sistemlerine bağlanarak diğer ana senaryoyu ele alınacaktır.

SAP sistemlerine uzaktan erişim

Azure Resource Manager ile, artık eski Klasik modelde olduğu gibi varsayılan uç nokta yoktur. Bir Azure Resource Manager VM 'nin tüm bağlantı noktaları şu kadar sürede açıktır:

  1. Alt ağ veya ağ arabirimi için ağ güvenlik grubu tanımlanmadı. Azure VM 'lerine yönelik ağ trafiğine, "ağ güvenlik grupları" adı verilir. Daha fazla bilgi için bkz. Ağ Güvenlik Grubu (NSG) nedir?
  2. ağ arabirimi için tanımlı Azure Load Balancer yok

Bu makaledeaçıklandığı gibi klasik model ve ARM arasındaki mimari farkını inceleyin.

Internet üzerinden SAP System ve SAP GUI bağlantısı yapılandırması

Bu konunun ayrıntılarını açıklayan bu makaleye bakın: Azure 'DA SAP sistemine bağlanırken SAP GUI bağlantısı kapatıldı

VM içinde güvenlik duvarı Ayarlar değiştirme

SAP sisteminize gelen trafiğe izin vermek için sanal makinelerinizde güvenlik duvarının yapılandırılması gerekebilir.


Windows logo. Windows

varsayılan olarak, Azure dağıtılan bir VM içindeki Windows güvenlik duvarı açıktır. Artık SAP bağlantı noktasının açılmasına izin vermeniz gerekir, aksi takdirde SAP GUI bağlantısı yapamaz. Bunu yapmak için:

  • gelişmiş Ayarlar Control panel\system ve Security \ Windows Firewall ' i açın.
  • Şimdi gelen kurallara sağ tıklayıp Yeni kural' ı seçin.
  • Aşağıdaki sihirbazda yeni bir bağlantı noktası kuralı oluşturmayı tercih edin.
  • Sihirbazın bir sonraki adımında, ayarı TCP ' de bırakın ve açmak istediğiniz bağlantı noktası numarasını yazın. SAP örnek KIMLIĞINIZ 00 olduğundan, 3200 sürdü. Örneğinizin farklı bir örnek numarası varsa, daha önce örnek numarasına göre tanımladığınız bağlantı noktası açılmalıdır.
  • Sihirbazın bir sonraki bölümünde, bağlantıya Izin ver ' in işaretli olması gerekir.
  • Sihirbazın bir sonraki adımında, kuralın etki alanı, özel ve genel ağ için uygulanıp uygulanmadığını tanımlamanız gerekir. Gereksinimleriniz için gerekliyse ayarlayın. Bununla birlikte, genel ağ üzerinden SAP GUI ile bağlantı kurarak, kuralın genel ağa uygulanmış olması gerekir.
  • Sihirbazın son adımında, kuralı adlandırın ve son' a basarak kaydedin.

Kural hemen etkili olur.

Bağlantı noktası kuralı tanımı

Linux logosu. Linux

Azure Marketi 'ndeki Linux görüntüleri, Iptables güvenlik duvarını varsayılan olarak etkinleştirmez ve SAP sisteminizin bağlantısı çalışmalıdır. İptables veya başka bir güvenlik duvarını etkinleştirdiyseniz, Iptables ' ın (xx, SAP sisteminizin sistem numarasıdır) numaralı bağlantı noktasına gelen TCP trafiğine izin vermek için kullanılan güvenlik duvarının belgelerine bakın.


Güvenlik önerileri

SAP GUI, çalıştıran hiçbir SAP örneğine (bağlantı noktası 32xx) hemen bağlanamaz, ancak önce SAP ileti sunucusu işlemine (bağlantı noktası 36XX) açılan bağlantı noktası aracılığıyla bağlanır. Geçmişte, uygulama örneklerine yönelik iç iletişim için ileti sunucusu tarafından aynı bağlantı noktası kullanılmıştır. Şirket içi uygulama sunucularının Azure 'daki bir ileti sunucusuyla yanlışlıkla iletişim kurmasını engellemek için iç iletişim bağlantı noktaları değiştirilebilir. SAP ileti sunucusuyla uygulama örnekleri arasındaki iç iletişimin, proje testi için bir geliştirme kopyası gibi şirket içi sistemlerden kopyalanmış olan sistemlerdeki farklı bir bağlantı noktası numarasıyla değiştirilmesi kesinlikle önerilir. Bu, varsayılan profil parametresiyle yapılabilir:

rdisp/msserv_internal

SAP ileti sunucusu için güvenlik Ayarlar bölümünde belgelendiği gibi

SAP NetWeaver demo/eğitim senaryosuna sahip tek VM

Azure Cloud Services yalıtılmış olarak aynı VM adlarıyla tek VM SAP tanıtım sistemlerini çalıştırma

Bu senaryoda, tüm eğitim/tanıtım senaryosunun tek bir sanal makinede bulunduğu tipik bir eğitim/tanıtım sistemi senaryosu uygulamamız. Dağıtımın VM görüntü şablonları aracılığıyla yapıldığını varsayıyoruz. Ayrıca, aynı ada sahip VM 'lerle birlikte bu tanıtım/seyahat sanal makinelerinin birden çok sürümünün dağıtılması gerektiğini varsaydık. Tüm eğitim sistemleri, şirket içi varlıklarınızla bağlantı sahibi değildir ve karma dağıtıma karşı bir yönlerdir.

Bu belgede, bu belgede Azure IÇIN SAP Ile VM 'Leri hazırlama başlıklı bölümün bazı bölümlerinde açıklandığı gıbı bir VM görüntüsü oluşturdunuz.

Senaryoyu uygulamak için olayların sırası şuna benzer:

PowerShell
  • Her eğitim/tanıtım dünyası için yeni bir kaynak grubu oluşturun
$rgName = "SAPERPDemo1"
New-AzResourceGroup -Name $rgName -Location "North Europe"
  • Yönetilen diskleri kullanmak istemiyorsanız yeni bir depolama hesabı oluşturun
$suffix = Get-Random -Minimum 100000 -Maximum 999999
$account = New-AzStorageAccount -ResourceGroupName $rgName -Name "saperpdemo$suffix" -SkuName Standard_LRS -Kind "Storage" -Location "North Europe"
  • Aynı konak adının ve IP adreslerinin kullanımını etkinleştirmek için her eğitim/tanıtım dünyası için yeni bir sanal ağ oluşturun. Sanal ağ, yalnızca bağlantı noktası 3389 ' e giden trafiğe izin veren bir ağ güvenlik grubu tarafından korunmuştur ve SSH için bağlantı noktası 22 ' dir.
# Create a new Virtual Network
$rdpRule = New-AzNetworkSecurityRuleConfig -Name SAPERPDemoNSGRDP -Protocol * -SourcePortRange * -DestinationPortRange 3389 -Access Allow -Direction Inbound -SourceAddressPrefix * -DestinationAddressPrefix * -Priority 100
$sshRule = New-AzNetworkSecurityRuleConfig -Name SAPERPDemoNSGSSH -Protocol * -SourcePortRange * -DestinationPortRange 22 -Access Allow -Direction Inbound -SourceAddressPrefix * -DestinationAddressPrefix * -Priority 101
$nsg = New-AzNetworkSecurityGroup -Name SAPERPDemoNSG -ResourceGroupName $rgName -Location  "North Europe" -SecurityRules $rdpRule,$sshRule

$subnetConfig = New-AzVirtualNetworkSubnetConfig -Name Subnet1 -AddressPrefix  10.0.1.0/24 -NetworkSecurityGroup $nsg
$vnet = New-AzVirtualNetwork -Name SAPERPDemoVNet -ResourceGroupName $rgName -Location "North Europe"  -AddressPrefix 10.0.1.0/24 -Subnet $subnetConfig
  • İnternet 'ten sanal makineye erişmek için kullanılabilecek yeni bir genel IP adresi oluşturun
# Create a public IP address with a DNS name
$pip = New-AzPublicIpAddress -Name SAPERPDemoPIP -ResourceGroupName $rgName -Location "North Europe" -DomainNameLabel $rgName.ToLower() -AllocationMethod Dynamic
  • Sanal makine için yeni bir ağ arabirimi oluştur
# Create a new Network Interface
$nic = New-AzNetworkInterface -Name SAPERPDemoNIC -ResourceGroupName $rgName -Location "North Europe" -Subnet $vnet.Subnets[0] -PublicIpAddress $pip
  • Sanal makine oluşturur. Bu senaryo için, her VM aynı ada sahip olacaktır. Bu VM 'lerdeki SAP NetWeaver örneklerinin SAP SID 'SI de aynı olacaktır. Azure Kaynak grubu ' nda, VM 'nin adının benzersiz olması gerekir, ancak farklı Azure Kaynak gruplarında aynı ada sahip VM 'Leri çalıştırabilirsiniz. Linux için Windows veya ' root ' varsayılan ' Administrator ' hesabı geçerli değil. Bu nedenle, yeni bir yönetici kullanıcı adının bir parolayla birlikte tanımlanması gerekir. VM'nin boyutunun da tanımlanmalıdır.
#####
# Create a new virtual machine with an official image from the Azure Marketplace
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

# select image
$vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "MicrosoftWindowsServer" -Offer "WindowsServer" -Skus "2012-R2-Datacenter" -Version "latest"
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "SUSE" -Offer "SLES-SAP" -Skus "12-SP1" -Version "latest"
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "RedHat" -Offer "RHEL" -Skus "7.2" -Version "latest"
# $vmconfig = Set-AzVMSourceImage -VM $vmconfig -PublisherName "Oracle" -Offer "Oracle-Linux" -Skus "7.2" -Version "latest"
# $vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig
#####
# Create a new virtual machine with a VHD that contains the private image that you want to use
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$diskName="osfromimage"
$osDiskUri=$account.PrimaryEndpoints.Blob.ToString() + "vhds/" + $diskName  + ".vhd"

$vmconfig = Set-AzVMOSDisk -VM $vmconfig -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage -SourceImageUri <path to VHD that contains the OS image> -Windows
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred
#$vmconfig = Set-AzVMOSDisk -VM $vmconfig -Name $diskName -VhdUri $osDiskUri -CreateOption fromImage -SourceImageUri <path to VHD that contains the OS image> -Linux
#$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig
#####
# Create a new virtual machine with a Managed Disk Image
#####
$cred=Get-Credential -Message "Type the name and password of the local administrator account."
$vmconfig = New-AzVMConfig -VMName SAPERPDemo -VMSize Standard_D11

$vmconfig = Add-AzVMNetworkInterface -VM $vmconfig -Id $nic.Id

$vmconfig = Set-AzVMSourceImage -VM $vmconfig -Id <Id of Managed Disk Image>
$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Windows -ComputerName "SAPERPDemo" -Credential $cred
#$vmconfig = Set-AzVMOperatingSystem -VM $vmconfig -Linux -ComputerName "SAPERPDemo" -Credential $cred

$vmconfig = Set-AzVMBootDiagnostics -Disable -VM $vmconfig
$vm = New-AzVM -ResourceGroupName $rgName -Location "North Europe" -VM $vmconfig
  • İsteğe bağlı olarak ek diskler ekleyin ve gerekli içeriği geri yükleme. Tüm blob adları (blobların URL'leri) Azure'da benzersiz olmalıdır.
# Optional: Attach additional VHD data disks
$vm = Get-AzVM -ResourceGroupName $rgName -Name SAPERPDemo
$dataDiskUri = $account.PrimaryEndpoints.Blob.ToString() + "vhds/datadisk.vhd"
Add-AzVMDataDisk -VM $vm -Name datadisk -VhdUri $dataDiskUri -DiskSizeInGB 1023 -CreateOption empty | Update-AzVM

# Optional: Attach additional Managed Disks
$vm = Get-AzVM -ResourceGroupName $rgName -Name SAPERPDemo
Add-AzVMDataDisk -VM $vm -Name datadisk -DiskSizeInGB 1023 -CreateOption empty -Lun 0 | Update-AzVM
CLI

Aşağıdaki örnek kod Linux üzerinde kullanılabilir. Örneğin Windows PowerShell'i yukarıda açıklandığı gibi kullanın veya örneği $rgName yerine %rgName% kullanmak üzere uyarlar ve ortam değişkenlerini Windows ayarlayın.

  • Her eğitim/tanıtım ortamı için yeni bir kaynak grubu oluşturma
rgName=SAPERPDemo1
rgNameLower=saperpdemo1
az group create --name $rgName --location "North Europe"
  • Yeni depolama hesabı oluşturma
az storage account create --resource-group $rgName --location "North Europe" --kind Storage --sku Standard_LRS --name $rgNameLower
  • Aynı ana bilgisayar adı ve IP adreslerinin kullanımını etkinleştirmek için her eğitim/tanıtım ortamı için yeni bir sanal ağ oluşturun. Sanal ağ, Uzak Masaüstü erişimini etkinleştirmek için yalnızca 3389 bağlantı noktasına gelen trafiğe ve SSH için 22 bağlantı noktasına izin veren bir Ağ Güvenlik Grubu tarafından korunur.
az network nsg create --resource-group $rgName --location "North Europe" --name SAPERPDemoNSG
az network nsg rule create --resource-group $rgName --nsg-name SAPERPDemoNSG --name SAPERPDemoNSGRDP --protocol \* --source-address-prefix \* --source-port-range \* --destination-address-prefix \* --destination-port-range 3389 --access Allow --priority 100 --direction Inbound
az network nsg rule create --resource-group $rgName --nsg-name SAPERPDemoNSG --name SAPERPDemoNSGSSH --protocol \* --source-address-prefix \* --source-port-range \* --destination-address-prefix \* --destination-port-range 22 --access Allow --priority 101 --direction Inbound

az network vnet create --resource-group $rgName --name SAPERPDemoVNet --location "North Europe" --address-prefixes 10.0.1.0/24
az network vnet subnet create --resource-group $rgName --vnet-name SAPERPDemoVNet --name Subnet1 --address-prefix 10.0.1.0/24 --network-security-group SAPERPDemoNSG
  • İnternet'den sanal makineye erişmek için kullanılan yeni bir genel IP adresi oluşturma
az network public-ip create --resource-group $rgName --name SAPERPDemoPIP --location "North Europe" --dns-name $rgNameLower --allocation-method Dynamic
  • Sanal makine için yeni bir ağ arabirimi oluşturma
az network nic create --resource-group $rgName --location "North Europe" --name SAPERPDemoNIC --public-ip-address SAPERPDemoPIP --subnet Subnet1 --vnet-name SAPERPDemoVNet
  • Sanal makine oluşturur. Bu senaryo için her VM'nin adı aynı olur. Bu VM'lerde bulunan SAP NetWeaver örneklerinin SAP SID'si de aynı olur. Azure Kaynak Grubu içinde VM'nin adının benzersiz olması gerekir, ancak farklı Azure Kaynak Gruplarında vm'leri aynı adla çalıştırabilirsiniz. Linux için 'root' Windows varsayılan 'Administrator' hesabı geçerli değildir. Bu nedenle, yeni bir yönetici kullanıcı adı bir parolayla birlikte tanımlanmalıdır. VM'nin boyutunun da tanımlanmalıdır.
#####
# Create virtual machines using storage accounts
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image MicrosoftWindowsServer:WindowsServer:2012-R2-Datacenter:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image SUSE:SLES-SAP:12-SP1:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image RedHat:RHEL:7.2:latest --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image "Oracle:Oracle-Linux:7.2:latest" --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --authentication-type password

#####
# Create virtual machines using Managed Disks
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image MicrosoftWindowsServer:WindowsServer:2012-R2-Datacenter:latest --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image SUSE:SLES-SAP:12-SP1:latest --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image RedHat:RHEL:7.2:latest --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --authentication-type password
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --image "Oracle:Oracle-Linux:7.2:latest" --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --authentication-type password
#####
# Create a new virtual machine with a VHD that contains the private image that you want to use
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --os-type Windows --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --image <path to image vhd>
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --os-type Linux --admin-username <username> --admin-password <password> --size Standard_D11 --use-unmanaged-disk --storage-account $rgNameLower --storage-container-name vhds --os-disk-name os --image <path to image vhd> --authentication-type password

#####
# Create a new virtual machine with a Managed Disk Image
#####
az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --image <managed disk image id>
#az vm create --resource-group $rgName --location "North Europe" --name SAPERPDemo --nics SAPERPDemoNIC --admin-username <username> --admin-password <password> --size Standard_DS11_v2 --os-disk-name os --image <managed disk image id> --authentication-type password
  • İsteğe bağlı olarak ek diskler ekleyin ve gerekli içeriği geri yükleme. Tüm blob adları (blobların URL'leri) Azure'da benzersiz olmalıdır.
# Optional: Attach additional VHD data disks
az vm unmanaged-disk attach --resource-group $rgName --vm-name SAPERPDemo --size-gb 1023 --vhd-uri https://$rgNameLower.blob.core.windows.net/vhds/data.vhd  --new

# Optional: Attach additional Managed Disks
az vm disk attach --resource-group $rgName --vm-name SAPERPDemo --size-gb 1023 --disk datadisk --new
Şablon

Azure-quickstart-templates deposundaki örnek şablonları GitHub.

Azure'da iletişim kuran bir dizi VM uygulama

Bu karma olmayan senaryo, tanıtım/eğitim senaryosunu temsil eden yazılımın birden çok VM'ye yayma amacıyla eğitim ve tanıtım amaçlı tipik bir senaryodur. Farklı VM'lerde yüklü olan farklı bileşenlerin birbirleriyle iletişim kurması gerekir. Yine bu senaryoda hiçbir şirket içi ağ iletişimi veya şirket içi ve şirket içi arası senaryo gerekli değildir.

Bu senaryo, bu belgenin SAP NetWeaver ile Tek VM tanıtım/eğitim senaryosu bölümünde açıklanan yüklemenin bir uzantısıdır. Bu durumda, mevcut bir kaynak grubuna daha fazla sanal makine eklenir. Aşağıdaki örnekte eğitim ortamı SAP ASCS/SCS VM'lerinden, DBMS çalıştıran bir VM'den ve SAP Uygulama Sunucusu örneği VM'lerinden oluşur.

Bu senaryoyu oluşturmadan önce, daha önce senaryoda zaten alıştırma yapılan temel ayarları düşünmeniz gerekir.

Kaynak Grubu ve Sanal Makine adlandırması

Tüm kaynak grubu adları benzersiz olmalıdır. >-soneki gibi <rg-name kaynaklarınızı adlandırma düzeninizi geliştirin.

Sanal makine adının kaynak grubu içinde benzersiz olması gerekir.

Farklı VM'ler arasındaki iletişim için Ağ ayarlama

Azure Sanal Ağı içindeki VM kümesi

Aynı eğitim/tanıtım ortamının kopyaları ile adlandırma çakışmalarını önlemek için her alan için bir Azure Sanal Ağ oluşturmanız gerekir. DNS ad çözümlemesi Azure tarafından sağlanır veya Azure dışında kendi DNS sunucularınızı yapılandırabilirsiniz (burada daha fazla tartışılacaktır). Bu senaryoda, kendi DNS'mizi yapılandırmaz. Tek bir Azure Sanal Ağı içindeki tüm sanal makineler için konak adlarından iletişim etkinleştirilir.

Eğitim veya tanıtım ortamlarını sanal ağlara göre ayırmanın nedenleri yalnızca kaynak gruplarıyla ilgili değildir:

  • Ayar olarak SAP ortamının kendi AD/OpenLDAP'sı ve etki alanı sunucusunun da her bir ortamın parçası olması gerekir.
  • Ayarlama olarak SAP ortamı, sabit IP adresleriyle çalışması gereken bileşenlere sahiptir.

Azure Sanal Ağları ve bunları tanımlama hakkında daha fazla ayrıntı bu makalede bulunabilir.

Kurumsal ağ bağlantısına sahip SAP VM'lerini dağıtma (Şirketler Arası)

SAP ortamını çalıştırarak dağıtımı üst düzey DBMS sunucuları, uygulama katmanları için şirket içi sanallaştırılmış ortamlar ve daha küçük 2 katmanlı yapılandırılmış SAP sistemleri ile Azure IaaS arasında bölmek istiyor. Temel varsayım, bir SAP ortamı içindeki SAP sistemlerinin dağıtım biçimlerinden bağımsız olarak birbirleriyle ve şirkete dağıtılan diğer birçok yazılım bileşeniyle iletişim kurması gerekmektedir. Ayrıca, SAP GUI veya diğer arabirimlerle bağlanan son kullanıcı için dağıtım formu tarafından hiçbir fark yoktur. Bu koşullar yalnızca şirket içi Active Directory/OpenLDAP ve DNS hizmetleri siteden siteye/çok siteli bağlantı ya da Azure ExpressRoute gibi özel bağlantılar aracılığıyla Azure sistemlerine genişletilmiş olduğunda karşı Azure ExpressRoute.

SAP ortamı senaryosu

Şirket içi ve hibrit senaryo, aşağıdaki grafiklerde olduğu gibi kabaca açıklanmıştır:

Şirket içi ve Azure varlıkları arasında Siteden Siteye bağlantı

En düşük gereksinim, Tarayıcı erişimi için SSL/TLS veya Azure hizmetleri için sistem erişimi için VPN tabanlı bağlantılar gibi güvenli iletişim protokollerinin kullanımıdır. Şirketler, şirket ağıyla Azure arasındaki VPN bağlantısını farklı bir şekilde ele alır. Bazı şirketler tüm bağlantı noktalarını boş bir şekilde açabilir. Diğer bazı şirketler hangi bağlantı noktalarını açmaları gerekenleri vb. net bir şekilde ifade etmek istiyor olabilir.

Tipik SAP iletişim bağlantı noktalarının aşağıdaki tabloda listelenmiştir. Temelde SAP ağ geçidi bağlantı noktasını açmak yeterlidir.

Hizmet Bağlantı Noktası Adı Örnek <nn> = 01 Varsayılan Aralık (min-max) Yorum
Dağıtıcı sapdp <nn> bkz. * 3201 3200 - 3299 SAP Dispatcher, sap GUI tarafından Windows Java için kullanılır
İleti sunucusu sapms <sid> bkz** 3600 ücretsiz sapms<anySID> sid = SAP-System-ID
Ağ geçidi sapgw <nn> bkz* 3301 serbest CPIC ve RFC iletişimi için kullanılan SAP ağ geçidi
SAP yönlendiricisi sapdp99 3299 serbest Yüklemeden sonra yalnızca CI (merkezi örnek) Hizmet adları /etc/services içinde rastgele bir değere yeniden atanabilir.

*) nn = SAP Örnek Numarası

**) sid = SAP-System-ID

SAP ürünlerine göre farklı SAP ürünleri veya hizmetleri için gereken bağlantı noktaları hakkında daha ayrıntılı bilgi burada https://scn.sap.com/docs/DOC-17124 bulunabilir. Bu belgeyle, belirli SAP ürünleri ve senaryoları için gereken VPN cihazında ayrılmış bağlantı noktalarını açabilirsiniz.

Böyle bir senaryoda VM'leri dağıtırken kullanılan diğer güvenlik önlemleri, erişim kurallarını tanımlamak için bir Ağ Güvenlik Grubu oluşturmak olabilir.

Azure'da SAP örneğinden yerel bir ağ yazıcısı üzerinde yazdırma

Şirket İçi Ve Şirket İçi Senaryolarda TCP/IP üzerinden yazdırma

Bir Azure VM'de şirket içi TCP/IP tabanlı ağ yazıcılarınızı ayarlama, bir VPN Siteden Siteye tüneliniz veya ExpressRoute bağlantınız olduğu varsayıldığına göre genel olarak kurumsal ağ ile aynıdır.


Windows logo. Windows

Bunu yapmak için:

  • Bazı ağ yazıcıları, yazıcınızı bir Azure VM'sinde ayarlamayı kolaylaştıran bir yapılandırma sihirbazı ile birlikte gelir. Yazıcıyla birlikte hiçbir sihirbaz yazılımı dağıtılmasa, yazıcıyı el ile ayarlamanın yolu yeni bir TCP/IP yazıcı bağlantı noktası oluşturmaktır.
  • Denetim Masası-> cihazları ve yazıcıları açın-> bir yazıcı ekleyin
  • TCP/IP adresi veya ana bilgisayar adı kullanarak yazıcı ekle seçeneğini belirleyin
  • Yazıcının IP adresini yazın
  • Yazıcı bağlantı noktası standart 9100
  • Gerekirse uygun yazıcı sürücüsünü el ile yükleyebilirsiniz.

Linux logosu. Linux

  • Windows gibi bir ağ yazıcısı yüklemek için standart yordamı izlemeniz yeterlidir
  • SUSE veya Red Hat için genel Linux kılavuzlarını ve yazıcı ekleme hakkında Oracle Linux izlemeniz yeterlidir.

Ağ yazdırma

Şirket Içi senaryoda SMB (paylaşılan yazıcı) üzerinden ana bilgisayar tabanlı yazıcı

Ana bilgisayar tabanlı yazıcılar, tasarıma göre ağa uyumlu değildir. Ancak, yazıcı yerleşik bir bilgisayara bağlandığı sürece, ana bilgisayar tabanlı bir yazıcı, bir ağdaki bilgisayarlar arasında paylaşılabilir. şirket ağınızı siteden siteye veya expressroute 'a Bağlan ve yerel yazıcınızı paylaşabilirsiniz. SMB protokolü, ad hizmeti olarak DNS yerine NetBIOS kullanır. NetBIOS ana bilgisayar adı, DNS ana bilgisayar adından farklı olabilir. Standart durum, NetBIOS ana bilgisayar adının ve DNS ana bilgisayar adının aynı olduğu durumdur. DNS etki alanı NetBIOS ad alanında anlamlı değildir. Buna uygun olarak, DNS ana bilgisayar adı ve DNS etki alanından oluşan tam DNS ana bilgisayar adı Netbıos ad alanında kullanılmamalıdır.

Yazıcı paylaşma, ağda benzersiz bir adla tanımlanır:

  • SMB konağının ana bilgisayar adı (her zaman gerekli).
  • Paylaşımın adı (her zaman gerekli).
  • Yazıcı paylaşımının SAP sistemiyle aynı etki alanında olmaması durumunda etki alanının adı.
  • Ayrıca, yazıcı paylaşımında erişim için bir Kullanıcı adı ve parola gerekebilir.

Nasıl yapılır:


Windows logo. Windows

Yerel yazıcınızı paylaşabilirsiniz. Azure VM 'de Windows gezginini açın ve yazıcının share adını yazın. Bir yazıcı yükleme Sihirbazı, yükleme sürecinde size kılavuzluk eder.

Linux logosu. Linux

Linux 'ta ağ yazıcılarını yapılandırmaya ilişkin bazı örnekler aşağıda verilmiştir veya Linux 'ta yazdırmayla ilgili bir bölüm dahil olmak üzere. VM bir VPN 'nin parçası olduğu sürece, Azure Linux VM 'de aynı şekilde çalışır:


USB yazıcı (yazıcı iletme)

Azure 'da Uzak Masaüstü Hizmetleri kullanıcılara, uzak bir oturumdaki yerel yazıcı cihazlarına erişim sağlama olanağı yoktur.


Windows logo. Windows

Windows ile yazdırma hakkında daha fazla ayrıntı aşağıda bulunabilir: https://technet.microsoft.com/library/jj590748.aspx .


SAP Azure sistemlerini şirket içinde düzeltme ve taşıma sistemi (TMS) ile tümleştirme

SAP değişikliği ve taşıma sisteminin (TMS), yatay içindeki sistemler arasında aktarım isteklerini dışarı ve içeri aktarmak üzere yapılandırılması gerekir. SAP sisteminin (DEV) geliştirme örneklerinin Azure 'da bulunduğunu, ancak kalite güvencesi (QA) ve üretken sistemleri (PRD) Şirket içi olduğunu varsayalım. Ayrıca, merkezi bir aktarım dizini olduğunu varsayalım.

Taşıma etki alanını yapılandırma

Aktarım etki alanı denetleyicisini yapılandırmabölümünde açıklandığı gibi, aktarım etki alanı denetleyicisi olarak atadığınız sistemde taşıma etki alanınızı yapılandırın. Bir sistem kullanıcısı TMSADM oluşturulur ve gerekli RFC hedefi oluşturulur. İşlem SM59 kullanarak bu RFC bağlantılarını kontrol edebilirsiniz. Ana bilgisayar adı çözümlemesi, aktarım etki alanınız genelinde etkinleştirilmelidir.

Nasıl yapılır:

  • Senaryomızda, şirket içi QAS sisteminin CTS etki alanı denetleyicisi olacağını karardık. İşlem STMS çağrısı yapın. TMS iletişim kutusu görüntülenir. Taşıma etki alanını Yapılandır iletişim kutusu görüntülenir. (Bu iletişim kutusu yalnızca henüz bir taşıma etki alanını yapılandırmadıysanız görüntülenir.)
  • Otomatik olarak oluşturulan TMSADM Kullanıcı (SM59-> ABAP bağlantısı-> TMSADM@E61.DOMAIN_E61 -> Ayrıntılar-> Utilities (d)-> yetkilendirme testi) olduğundan emin olun. İşlemin ilk ekranında, bu SAP sisteminin artık burada gösterildiği gibi aktarım etki alanı denetleyicisi olarak çalıştığını göstermesi gerekir:

Etki alanı denetleyicisindeki işlem STMS başlangıç ekranı

Aktarım etki alanına SAP sistemleri dahil

Bir aktarım etki alanında SAP sisteminin dahil edilmesi sırası şu şekilde görünür:

  • Azure 'daki GELIŞTIRME sisteminde, aktarım sistemine (Istemci 000) gidin ve işlem STMS ' ı çağırın. İletişim kutusundan diğer yapılandırma ' yı seçin ve Içerme sistemiyle birlikte etki alanına devam edin. Etki alanı denetleyicisini hedef konak olarak belirtin (Aktarım etki ALANıNDAKI SAP sistemleri dahil). Sistem artık aktarım etki alanına dahil edilmesini bekliyor.
  • Güvenlik nedenleriyle isteğinizi onaylamak için etki alanı denetleyicisine geri gitmeniz gerekir. Sisteme genel bakış ve bekleyen sistemi Onayla ' yı seçin. Sonra istemi onaylayın ve yapılandırma dağıtılır.

Bu SAP sistemi artık aktarım etki alanındaki tüm diğer SAP sistemleri hakkında gerekli bilgileri içermektedir. Aynı zamanda, yeni SAP sisteminin adres verileri diğer tüm SAP sistemlerine gönderilir ve SAP sistemi aktarım denetimi programının aktarım profiline girilir. Etki alanının aktarım dizinine yönelik RFC 'Lerin ve erişimin çalışıp çalışmadığını denetleyin.

Belge değişikliği ve taşıma sistemindeaçıklandığı gibi, aktarım sisteminizin yapılandırmasına devam edin.

Nasıl yapılır:

  • Şirket içi STMS 'nizin doğru yapılandırıldığından emin olun.
  • Aktarım etki alanı denetleyicisinin ana bilgisayar adının Azure 'daki sanal makineniz tarafından çözümlenebildiğinden ve tam olarak Visa olduğundan emin olun.
  • Çağrı işlemi STMS-> diğer yapılandırma-> dahil etme sistemi.
  • Şirket içi TMS sisteminde bağlantıyı onaylayın.
  • Taşıma yollarını, grupları ve katmanları her zamanki gibi yapılandırın.

Siteden siteye bağlı çapraz şirket senaryolarında, şirket içi ve Azure arasındaki gecikme hala önemli olabilir. Geliştirme ve test sistemleri aracılığıyla veya farklı sistemlere taşıma ya da destek paketleri uygulama hakkında bilgi almak için nesneleri taşıma sırasını izliyoruz, merkezi aktarım dizininin konumuna bağlı olduğunu fark edersiniz. Bu durumda, bazı sistemler merkezi aktarım dizinindeki yüksek gecikme süresine veya veri yazmaya neden olur. Bu durum, farklı sistemlerin veri merkezleri arasında önemli mesafe ile farklı veri merkezlerinde yayıldığı SAP yatay yapılandırmalarına benzer.

Bu gecikme süresini aşmak ve sistemin aktarım dizininden okuma ya da yazma sırasında hızla çalışmasını sağlamak için, iki STMS taşıma etki alanı (bir tane şirket içi ve biri Azure 'daki sistemlerle bir tane) ayarlayabilir ve aktarım etki alanlarını bağlayabilirsiniz. SAP TMS 'de bu kavramın arkasındaki ilkeleri açıklayan bu belgeleridenetleyin.

Nasıl yapılır:

Azure 'da ve şirket içinde bulunan SAP örnekleri arasında RFC trafiği (Şirket Içi)

Şirket içinde ve Azure 'da olan sistemler arasındaki RFC trafiği çalışmalıdır. Hedef sisteme yönelik bir RFC bağlantısı tanımlamanız gereken kaynak sistemde bir bağlantı çağrı işlemi SM59 ayarlamak için. Yapılandırma, bir RFC bağlantısının standart kurulumuna benzerdir.

Şirketler arası senaryoda, birbirleriyle iletişim kurması gereken SAP sistemlerini çalıştıran VM 'Lerin aynı etki alanında olduğunu varsayıyoruz. Bu nedenle, SAP sistemleri arasında bir RFC bağlantısı kurulumu, kurulum adımlarından ve şirket içi senaryolardaki girişlerden farklı değildir.

Azure 'da bulunan SAP örneklerinden yerel dosya paylaşımlarına erişme veya bunun tersi

Azure 'da bulunan SAP örneklerinin, şirket içi Şirket içindeki dosya paylaşımlarına erişmesi gerekir. Ayrıca, şirket içi SAP örneklerinin Azure 'da bulunan dosya paylaşımlarına erişmesi gerekir. Dosya paylaşımlarını etkinleştirmek için, yerel sistemde izinleri ve paylaşım seçeneklerini yapılandırmanız gerekir. Azure ile veri merkeziniz arasındaki VPN veya ExpressRoute bağlantısı üzerindeki bağlantı noktalarını açmayı unutmayın.

Desteklenebilirlik

SAP için Azure uzantısı

Görev açısından kritik SAP sistemlerinin bazı parçalarını, VM 'lerde yüklü olan SAP konak Aracısı örneklerine akışa almak için, SAP için bir Azure (VM) uzantısının dağıtılan VM 'Ler için yüklenmesi gerekir. SAP 'nin talepleri SAP uygulamalarına özel olduğundan, Microsoft gerekli işlevselliği Azure 'a genel olarak uygulamamaya karar vermemeye karar verdi, ancak müşterilerin Azure 'da çalışan sanal makinelere gerekli VM uzantısını ve yapılandırmasını dağıtmaları için bırakın. Bununla birlikte, SAP için Azure VM uzantısının dağıtım ve yaşam döngüsü yönetimi, Azure tarafından çoğunlukla otomatikleştirilir.

Çözüm tasarımı

SAP konak Aracısı 'nı etkinleştirmek için geliştirilen çözüm, Azure VM Aracısı ve uzantı çerçevesinin mimarisine dayanır. Azure VM Aracısı ve uzantı çerçevesinin fikri, bir VM içindeki Azure VM Uzantısı galerisinde bulunan yazılım uygulamalarının yüklenmesine izin vermenizde yarar vardır. Bu kavramın arkasındaki prensibi, özel işlevlerin bir VM 'ye dağıtılması ve dağıtım zamanında bu yazılımın yapılandırılması için (SAP için Azure uzantısı gibi durumlarda) izin vermenizde yarar vardır.

vm 'de belirli Azure vm uzantılarının işlenmesine izin veren ' azure vm aracısı ', Azure portal sanal makine oluşturmada varsayılan olarak Windows sanal makinelere eklenir. SUSE, Red hat veya Oracle Linux söz konusu olduğunda, VM Aracısı zaten Azure Marketi görüntüsünün bir parçasıdır. Bu durumda, bir Linux sanal makinesini Şirket içinden Azure 'a karşıya yükleyerek VM aracısının el ile yüklenmesi gerekir.

Azure 'da SAP konak aracısına Azure altyapı bilgilerini sağlamak için çözümün temel yapı taşları şöyle görünür:

Microsoft Azure Uzantı bileşenleri

Yukarıdaki blok diyagramında gösterildiği gibi, çözümün bir parçası Azure VM görüntüsünde ve Azure uzantı galerisinde barındırılır ve bu da Azure Işlemleri tarafından yönetilen küresel olarak çoğaltılan bir depodur. SAP için Azure 'un yeni sürümlerini yayımlamak üzere SAP 'nin Azure uygulamasında çalışan SAP/MS ekibinin sorumluluğundadır.

yeni bir Windows vm dağıtırken, Azure vm aracısı sanal makineye otomatik olarak eklenir. Bu aracının işlevi, VM 'lerin Azure uzantılarının yükleme ve yapılandırmasını koordine etmek için kullanılır. Linux VM 'Leri için Azure VM Aracısı zaten Azure Marketi işletim sistemi görüntüsünün bir parçasıdır.

Ancak, hala müşteri tarafından yürütülmesi gereken bir adım vardır. Bu, performans koleksiyonunun etkinleştirilmesi ve yapılandırması. Yapılandırma ile ilgili işlem, bir PowerShell betiği veya CLı komutu tarafından otomatikleştirilir. PowerShell betiği, dağıtım kılavuzundaaçıklandığı gibi Microsoft Azure betik merkezi 'ne indirilebilir.

SAP için Azure uzantısının genel mimarisi şöyle görünür:

SAP için Azure uzantısı

Dağıtım sırasında bu PowerShell cmdlet 'lerini veya CLı komutunu kullanmanın ayrıntılı adımları için nasıl yapılır ve ayrıntılı adımlar için dağıtım kılavuzundaverilen yönergeleri izleyin.

Azure bulunan SAP örneğinin, SAProuter ile tümleştirilmesi

Azure 'da çalışan SAP örneklerinin de SAProuter 'tan erişilebilir olması gerekir.

SAP-Router ağ bağlantısı

Bir SAProuter, doğrudan IP bağlantısı yoksa katılım sistemleri arasında TCP/IP iletişimine izin vermez. Bu, ağ düzeyinde iletişim ortakları arasında uçtan uca bir bağlantının gerekli olmadığı avantajını sağlar. SAProuter, varsayılan olarak 3299 numaralı bağlantı noktasını dinliyor. SAP örneklerini bir SAProuter aracılığıyla bağlamak için, SAProuter dize ve ana bilgisayar adına herhangi bir bağlantı girişimi sağlamanız gerekir.

Java olarak SAP NetWeaver

Bu nedenle belgenin odağının genel veya SAP NetWeaver ABAP yığınında SAP NetWeaver. Bu küçük bölümde SAP Java yığınının belirli konuları listelenmiştir. en önemli sap NetWeaver Java özel tabanlı uygulamalardan biri sap Enterprise Portal. SAP PI ve SAP çözüm Yöneticisi gibi diğer SAP NetWeaver tabanlı uygulamalar hem SAP NetWeaver ABAP hem de Java yığınlarını kullanır. Bu nedenle, SAP NetWeaver Java Stack ile ilgili belirli yönleri de göz önünde bulundurmanız gerekir.

SAP Enterprise Portal

Şirketler arası senaryolarda dağıtım yapıyorsanız, bir Azure sanal makinesinde SAP portalının kurulumu, şirket içi bir yüklemeden farklı değildir. DNS, şirket içi tarafından yapıldığından, tek örneklerin bağlantı noktası ayarları şirket içi olarak yapılandırılmış şekilde yapılabilir. bu belgede açıklanan öneriler ve kısıtlamalar, sap Enterprise Portal veya genel olarak sap NetWeaver Java stack gibi bir uygulama için geçerlidir.

Sunulan SAP portalı

bazı müşterilerin özel bir dağıtım senaryosu, sanal makine konağı, siteden siteye VPN tüneli veya expressroute aracılığıyla şirket ağına bağlıyken SAP Enterprise Portal Internet 'e doğrudan maruz kalmaktır. Böyle bir senaryoda, belirli bağlantı noktalarının açık olduğundan ve güvenlik duvarı veya ağ güvenlik grubu tarafından engellenmediğinden emin olmanız gerekir.

İlk portal URI 'SI, http (s): <Portalserver>: bağlantı noktasının ' de SAP tarafından belgelendiği şekilde OLUŞTURULDUĞU 5XX00/ırj https://help.sap.com/saphelp_nw70ehp1/helpdata/de/a2/f9d7fed2adc340ab462ae159d19509/frameset.htm .

Uç nokta yapılandırması

SAP Enterprise Portal URL ve/veya bağlantı noktalarını özelleştirmek istiyorsanız, bu belgeleri denetleyin:

Azure sanal makinelerde çalışan SAP NetWeaver için yüksek kullanılabilirlik (HA) ve olağanüstü durum kurtarma (DR)

Terimlerin tanımı

Yüksek kullanılabilirlik (ha) terimi genellikle, aynı veri merkezinde yer alan yedekli, hataya dayanıklı veya yük devretme korumalı bileşenler aracılığıyla BT Hizmetleri için iş sürekliliği sağlayan bir teknoloji kümesiyle ilgilidir. Bu durumda, bir Azure bölgesi içinde.

Olağanüstü durum kurtarma (Dr) Ayrıca, BT Hizmetleri kesintisini ve bunların kurtarmasını, ancak genellikle yüzlerce kilometre kilometrede bulunan farklı veri merkezlerinde en aza indirme için de hedefleme. Bizim örneğimizde, genellikle aynı coğrafi bölge içindeki farklı Azure bölgeleri arasında veya müşteri olarak sizin tarafınızdan kurulacaktır.

Yüksek kullanılabilirliğe genel bakış

Azure 'da SAP yüksek kullanılabilirliği hakkındaki tartışmayı iki parçaya ayırabiliriz:

  • Azure altyapı yüksek kullanılabilirlik, örneğin Işlem (VM), ağ, depolama vb. ve SAP uygulama kullanılabilirliğini artırma avantajları.
  • SAP Uygulama yüksek kullanılabilirliği, ÖRNEĞIN, SAP yazılım bileşenleri IÇIN bir ha:
    • SAP uygulama sunucuları
    • SAP ASCS/SCS örneği
    • DB sunucusu

Azure altyapı HA ile nasıl birleştirilebilecek.

Azure 'da SAP yüksek kullanılabilirlik, şirket içi fiziksel veya sanal ortamda SAP yüksek kullanılabilirliğe kıyasla bazı farklılıklar içerir. SAP 'deki aşağıdaki kağıda, Windows üzerinde sanallaştırılmış ortamlarda standart SAP yüksek kullanılabilirlik konfigürasyonları açıklanmaktadır: https://scn.sap.com/docs/DOC-44415 . Linux için Windows için mevcut olan sapinst ile tümleşik SAP-HA yapılandırması yoktur. Linux için şirket içi SAP HA hakkında daha fazla bilgi edinin: https://scn.sap.com/docs/DOC-8541 .

Azure altyapı yüksek kullanılabilirliği

Şu anda% 99,9 olan tek VM SLA 'Sı var. Tek bir VM 'nin kullanılabilirliğinin nasıl görünebileceğini fikir almak için, farklı kullanılabilir Azure SLA 'ların ürününü oluşturabilirsiniz: https://azure.microsoft.com/support/legal/sla/ .

Hesaplamanın temeli ayda 30 gün veya 43200 dakikadır. Bu nedenle,% 0,05 kesinti süresi 21,6 dakikaya karşılık gelir. Her zamanki gibi, farklı hizmetlerin kullanılabilirliği aşağıdaki şekilde çarpılacaktır:

(Kullanılabilirlik hizmeti #1/100) * (kullanılabilirlik hizmeti #2/100) * (kullanılabilirlik hizmeti #3/100)

Like

(99,95/100) * (99,9/100) * (99,9/100) = 0,9975 veya genel olarak% 99,75 kullanılabilirliği.

Sanal makine (VM) yüksek kullanılabilirlik

Sanal makinelerinizin kullanılabilirliğini etkileyebilecek iki tür Azure platform olayı vardır: planlı bakım ve planlanmamış bakım.

  • Planlı bakım olayları, Microsoft tarafından, sanal makinelerinizin üzerinde çalıştığı platform altyapısının genel güvenilirlik, performans ve güvenliğini geliştirmek amacıyla temel alınan Azure platformunda yapılan düzenli güncelleştirmelerdir.
  • Plansız bakım olayları, sanal makinenizin altında yatan donanım ya da fiziksel altyapı bir şekilde arıza yaptığında gerçekleştirilir. Buna yerel ağ hataları, yerel disk hataları veya raf düzeyinde diğer hatalar dahildir. Böyle bir hata algılandığında, Azure platformu sanal makinenizi sanal makinenizi barındıran uygun olmayan fiziksel sunucudan sağlıklı fiziksel bir sunucuya otomatik olarak geçirilir. Bu tür olaylar nadirdir, ancak sanal makinenizin yeniden başlatılmasına da neden olabilir.

daha ayrıntılı bilgi için bkz. azure 'da Windows sanal makinelerin kullanılabilirliği ve azure 'da Linux sanal makinelerinin kullanılabilirliği.

Azure Depolama artıklığı

Microsoft Azure Depolama hesabınızdaki veriler, dayanıklılık ve yüksek kullanılabilirlik sağlamak için her zaman çoğaltılır ve Azure Depolama SLA 'sını, geçici donanım arızalarına karşı da karşılayarak sağlar.

azure Depolama, verilerin üç görüntüsünü varsayılan olarak tutarken, birden çok Azure diski arasında RAID5 veya RAID1 gerekli değildir.

daha ayrıntılı bilgi için bkz. Azure Depolama artıklığı.

SAP uygulamalarında daha yüksek kullanılabilirlik elde etmek için Azure altyapı VM yeniden başlatması kullanma

Linux üzerinde Windows Server yük devretme kümelemesi (WSFC) veya paceyapıcısı gibi işlevleri kullanmamaya karar verirseniz (şu anda yalnızca sles 12 ve üzeri için desteklenir), azure fiziksel sunucu altyapısının ve genel olarak temel alınan azure platformunun planlanmış ve planlanmamış kapalı kalma süresine karşı bir SAP sistemini korumak için azure VM yeniden başlatması kullanılır.

Not

Azure VM 'nin yeniden başlatılmasının birincil olarak uygulamaları DEĞIL, VM 'Leri koruduğu bahsetmek önemlidir. VM yeniden başlatma, SAP uygulamaları için yüksek kullanılabilirlik sunmaz, ancak belirli bir altyapı kullanılabilirliği düzeyi ve bu nedenle SAP sistemlerinin dolaylı olarak daha yüksek kullanılabilirliğini sunmaktadır. Planlı veya planlanmamış bir ana bilgisayar kesintisinden sonra VM 'yi yeniden başlatmak için gereken süre için SLA yoktur. Bu nedenle, bu yüksek kullanılabilirlik yöntemi, (A) SCS veya DBMS gibi bir SAP sisteminin kritik bileşenleri için uygun değildir.

Yüksek kullanılabilirlik için başka bir önemli altyapı öğesi depolama alanı. örneğin Azure Depolama SLA% 99,9 kullanılabilir. biri, disklerinin bulunduğu tüm vm 'leri tek bir azure Depolama hesabına dağıttığında, olası azure Depolama kullanım dışı kalması, bu azure Depolama hesabına yerleştirilmiş tüm vm 'lerin ve ayrıca bu sanal makinelerin içinde çalışan tüm SAP bileşenlerinin kullanılamamasına neden olur.

tüm vm 'leri tek bir Azure Depolama hesabına koymak yerine, her sanal makine için ayrılmış depolama hesapları da kullanabilirsiniz ve bu şekilde, birden çok bağımsız Azure Depolama hesabı kullanarak genel VM ve SAP uygulamasının kullanılabilirliğini artırabilirsiniz.

Azure yönetilen diskler, eklendiği sanal makinenin hata etki alanına otomatik olarak yerleştirilir. İki sanal makineyi bir kullanılabilirlik kümesine yerleştirirseniz ve yönetilen diskler kullanıyorsanız, platform yönetilen diskleri farklı hata etki alanlarına dağıtmayı da üstlenir. Premium Depolama kullanmayı planlıyorsanız, diskleri yönetme seçeneğini de kullanmanız önemle önerilir.

Azure altyapı HA ve depolama hesapları kullanan bir SAP NetWeaver sisteminin örnek mimarisi şuna benzeyebilir:

Azure altyapı HA ve depolama hesapları kullanan bir SAP NetWeaver sistemi gösteren diyagram.

Azure altyapı HA ve yönetilen diskler kullanan bir SAP NetWeaver sisteminin örnek mimarisi şuna benzeyebilir:

SAP uygulamasına daha yüksek kullanılabilirlik elde etmek için Azure altyapı HA kullanma

Kritik SAP bileşenleri için şu ana kadar şunu aldık:

  • SAP uygulama sunucularının yüksek kullanılabilirliği (AS)

    SAP uygulama sunucusu örnekleri, yedekli bileşenlerdir. Her SAP örneği, farklı bir Azure hata ve yükseltme etki alanında çalışan kendi VM 'sine dağıtılır (bkz. bölümler hata etki alanları ve yükseltme etki alanları). Bu, Azure kullanılabilirlik kümeleri kullanılarak yapılır (bkz. bölüm Azure kullanılabilirlik kümeleri). Bir Azure hata ya da yükseltme etki alanının olası planlanmış veya planlanmamış kullanım dışı kalması, sınırlı sayıda VM 'nin SAP olarak örnekleri olarak kullanılamamasına neden olur.

    her SAP, örnek olarak kendi azure Depolama hesabına yerleştirilir. bir azure Depolama hesabının olası olmamasından dolayı, sap örnek olarak yalnızca bir VM 'nin kullanılamamasına neden olur. bununla birlikte, bir azure aboneliği içinde azure Depolama hesapları sınırının olduğunu unutmayın. VM yeniden başlatıldıktan sonra (A) bir SCS örneğinin otomatik olarak başlamasını sağlamak için, sap örnekleri Için autostart' ı kullanarak bölümünde açıklanan, (a) SCS örneği başlangıç profilinde otomatik başlatma parametresini ayarladığınızdan emin olun. Ayrıca, daha fazla ayrıntı için SAP uygulama sunucuları için bölüm yüksek kullanılabilirliği bölümünü okuyun.

    yönetilen diskler kullanıyor olsanız da bu diskler bir Azure Depolama hesabında depolanır ve depolama kesintisi durumunda kullanılamayabilir.

  • Daha yüksek SAP (A) SCS örneği kullanılabilirliği

    Burada, VM 'yi yüklü SAP (A) SCS örneğiyle korumak için Azure VM yeniden başlatması kullanıyoruz. Azure 'da planlanmış veya planlanmamış kapalı kalma süresi söz konusu olduğunda, VM 'Ler kullanılabilir başka bir sunucuda yeniden başlatılır. Daha önce belirtildiği gibi, Azure VM yeniden başlatması öncelikle VM 'Leri korur, bu durumda (A) SCS örneği. VM yeniden başlatıldığında, SAP (A) SCS örneği için dolaylı olarak daha yüksek kullanılabilirliğe ulaşacağız. Sanal makine yeniden başlatıldıktan sonra (A) SCS örneğinin otomatik olarak başlamasını sağlamak için, sap örnekleri Için autostart 'ı kullanmabölümünde açıklanan, (a) SCS örneği başlangıç profilinde otomatik başlatma parametresi ayarladığınızdan emin olun. Yani, (A) SCS örneği tek bir VM 'de çalışan tek bir hata noktası (SPOF) olarak tüm SAP yatay kullanılabilirliği için belirleyici bir faktör olacaktır.

  • Daha yüksek DBMS sunucusunun kullanılabilirliği

    Burada SAP (A) SCS örnek kullanım örneğine benzer şekilde, VM 'yi yüklü olan DBMS yazılımıyla korumak için Azure VM yeniden başlatma 'yı kullanıyoruz ve VM yeniden başlatma aracılığıyla DBMS yazılımının daha yüksek kullanılabilirliğini elde ediyoruz. Tek bir VM 'de çalışan DBMS de bir SOF olur ve tüm SAP yatay kullanılabilirliği için belirleyici bir etkendir.

Azure IaaS 'de SAP uygulaması yüksek kullanılabilirliği

Tam SAP sistem yüksek kullanılabilirlik elde etmek için, tüm kritik SAP sistem bileşenlerini (örneğin, yedekli SAP uygulama sunucuları) ve SAP (A) SCS örneği ve DBMS gibi benzersiz bileşenleri (örneğin, tek başarısızlık noktası) korumanız gerekir.

SAP uygulama sunucuları için yüksek kullanılabilirlik

SAP uygulama sunucuları/iletişim örnekleri için, belirli bir yüksek kullanılabilirlik çözümü düşünmek gerekli değildir. Yüksek kullanılabilirlik, artıklık tarafından sağlanır ve bu sayede farklı sanal makinelerde yeterince yer vardır. Bunların tümü, planlanan bakım kapalı kalma süresi boyunca VM 'Lerin aynı anda güncelleştirilebileceği kaçınmak için aynı Azure kullanılabilirlik kümesine yerleştirilmelidir. Azure ölçek birimi içindeki farklı yükseltme ve hata etki alanları üzerinde oluşturulan temel işlevsellik, bölüm yükseltme etki alanlarındazaten sunulmuştur. Azure kullanılabilirlik kümeleri, bu belgenin bölüm Azure kullanılabilirlik kümelerinde sunulmuştur.

Azure ölçek birimi içindeki bir Azure kullanılabilirlik kümesi tarafından kullanılabilen, sonsuz sayıda hata ve yükseltme etki alanı yoktur. Bu, birden çok VM 'nin bir kullanılabilirlik kümesine yerleştirilmesi, daha önce veya daha sonraki bir VM 'nin aynı hata veya yükseltme etki alanında sona ereceği anlamına gelir.

Ayrılmış VM 'lerinde birkaç SAP uygulama sunucusu örneği dağıtma ve beş yükseltme etki alanı olduğunu varsayarsak, aşağıdaki resim sonunda ortaya çıktı. Bir kullanılabilirlik kümesi içindeki en fazla hata ve güncelleştirme etki alanı sayısı gelecekte değişebilir:

Azure 'da SAP uygulama sunucularının HA

Azure 'da SAP Merkezi Hizmetleri için yüksek kullanılabilirlik

Azure 'daki SAP merkezi hizmetlerinin yüksek kullanılabilirlik mimarisi için, giriş bilgileri olarak SAP NetWeaver Için yüksek kullanılabilirlik mimarisi ve senaryolar makalesine bakın. Bu makale, belirli işletim sistemleri için daha ayrıntılı açıklamalara işaret eder.

SAP veritabanı örneği için yüksek kullanılabilirlik

Tipik SAP DBMS HA kurulumu, DBMS yüksek kullanılabilirlik işlevinin, etkin DBMS örneğinden ikinci VM 'ye verileri pasif bir DBMS örneğine çoğaltmak için kullanıldığı iki DBMS VM 'yi temel alır.

DBMS 'nin genel ve özel DBMS için yüksek kullanılabilirlik ve olağanüstü durum kurtarma işlevlerinin yanı sıra, DBMS dağıtım kılavuzundade açıklanmaktadır.

Tam SAP sistemi için uçtan uca yüksek kullanılabilirlik

Azure 'da Windows ve Linux için bir tane olmak üzere Azure 'da tam SAP NetWeaver HA mimarisine yönelik iki örnek aşağıda verilmiştir.

yalnızca yönetilmeyen diskler: birçok SAP sistemini dağıtırken ve dağıtılan vm 'lerin sayısı, abonelik başına en fazla Depolama hesap sınırını aştığdığında, aşağıda açıklanan kavramların tehlikeye düşmesi gerekebilir. bu gibi durumlarda, vm 'lerin vhd 'lerinin tek bir Depolama hesabı içinde birleştirilmesi gerekir. Genellikle, farklı SAP sistemlerinin SAP uygulama katmanı VM 'lerinin VHD 'lerini birleştirerek bunu yapabilirsiniz. ayrıca, tek bir Azure Depolama hesabında farklı SAP sistemlerinin farklı DBMS vm 'lerinin farklı vhd 'lerini de birleştirdik. böylece, Azure Depolama hesapların ıops sınırları göz önünde tutulduğunda ( https://azure.microsoft.com/documentation/articles/storage-scalability-targets )

Windows logo. Windows HA

Azure ıaas 'de SQL Server SAP NetWeaver Application HA mimarisini gösteren diyagram.

Aşağıdaki Azure yapıları, altyapı sorunları ve ana bilgisayar düzeltme eki uygulama ile etkisini en aza indirmek için SAP NetWeaver sistemi için kullanılır:

  • Tam sistem Azure 'da dağıtılır (gerekli-DBMS katmanı, (A) SCS örneği ve tam uygulama katmanının aynı konumda çalıştırılması gerekir).
  • Tüm sistem bir Azure aboneliğinde (gerekli) çalışır.
  • Tüm sistem bir Azure sanal ağı içinde çalışır (gerekli).
  • Aynı sanal ağa ait tüm VM 'Ler de dahil olmak üzere bir SAP sisteminin VM 'lerinin üç kullanılabilirlik kümesine ayrılması mümkündür.
  • Her katmanın (örneğin, DBMS, Ass, uygulama sunucuları) adanmış bir kullanılabilirlik kümesi kullanması gerekir.
  • Bir SAP sisteminin DBMS örneklerini çalıştıran tüm VM 'Ler tek bir kullanılabilirlik kümesinde bulunur. yerel dbms yüksek kullanılabilirlik özellikleri kullanıldığından, SQL Server AlwaysOn veya Oracle Data Guard gibi birden çok sanal makinenin sistem başına çalıştığını varsayalım.
  • DBMS örnekleri çalıştıran tüm VM 'Ler kendi depolama hesabını kullanır. DBMS verileri ve günlük dosyaları, verileri eşitlerken DBMS yüksek kullanılabilirlik işlevleri kullanılarak bir depolama hesabından başka bir depolama hesabına çoğaltılır. tek bir depolama hesabının kullanım dışı kalması, tek bir SQL Windows küme düğümünün kullanılamamasına neden olur, ancak tüm SQL Server hizmeti değildir.
  • Bir SAP sisteminin (A) SCS örneği çalıştıran tüm VM 'Ler tek bir kullanılabilirlik kümesidir. bir Windows sunucusu yük devretme kümesi (WSFC), (A) SCS örneğini korumak için bu sanal makinelerin içinde yapılandırılır.
  • Bir SCS örneği çalıştıran tüm VM 'Ler kendi depolama hesabını kullanır. A SCS örnek dosyaları ve SAP Genel klasörü, bir depolama hesabından, SIOS Dataman çoğaltması kullanılarak başka bir depolama hesabına çoğaltılır. tek bir depolama hesabının olmaması, (a) bir scs Windows küme düğümünde kullanılamamasına neden olur, ancak (a) bir scs hizmeti değildir.
  • SAP uygulama sunucusu katmanını temsil eden tüm VM 'Ler üçüncü bir kullanılabilirlik kümesidir.
  • SAP uygulama sunucuları çalıştıran tüm VM 'Ler kendi depolama hesabını kullanır. Bir depolama hesabının olmaması, diğer SAP uygulama sunucularının çalışmaya devam ettiği bir SAP uygulama sunucusu üzerinde kullanılamamasına neden olur.

Aşağıdaki şekilde, yönetilen diskler kullanılarak aynı yatay gösterilmektedir.

Azure ıaas 'de SQL Server SAP NetWeaver Application HA mimarisi

Linux logosu. Linux 'ta HA

Azure 'da Linux 'ta SAP HA 'nin mimarisi, yukarıda açıklanan Windows temel olarak aynıdır. Desteklenen yüksek kullanılabilirliğe sahip çözümlerin listesi için SAP Note 1928533 bölümüne bakın.

SAP örnekleri için autostart 'ı kullanma

SAP, VM 'deki işletim sistemi başladıktan hemen sonra SAP örneklerinin başlatılması için gereken işlevselliği önerdi. SAP Bilgi Bankası makalesi 1909114' de tam adımlar belgelenmiştir. Ancak, örnek yeniden başlatmalarının sırası üzerinde bir denetim olmadığından, SAP 'nin birden fazla VM 'den etkilendiğini veya birden çok örnek VM başına çalıştırıldığı varsayıldığında, bu ayarı kullanmayı önermez. Bir VM 'deki bir SAP uygulama sunucusu örneğinin tipik bir Azure senaryosu ve tek bir VM 'nin yeniden başlatılması durumunda, autostart önemli değildir ve bu parametre eklenerek etkinleştirilebilir:

Autostart = 1

SAP ABAP ve/veya Java örneğinin başlangıç profiline.

Not

Autostart parametresinin bir kısmı de olabilir. daha ayrıntılı olarak, bu parametre, örneğin ilgili Windows/linux hizmeti başlatıldığında SAP ABAP veya Java örneğinin başlangıcını tetikler. Bu durum, işletim sisteminin önyüklemesinde büyük bir durumdur. Ancak, SAP hizmetlerinin yeniden başlatılması, SUM veya diğer güncelleştirmeler ya da yükseltmeler gibi SAP yazılım yaşam döngüsü yönetimi işlevlerinin de yaygın bir şeydir. Bu işlevler, bir örneğin otomatik olarak yeniden başlatılmasını beklemiyordu. Bu nedenle, bu tür görevler çalıştırılmadan önce autostart parametresi devre dışı bırakılmalıdır. Autostart parametresi, yoks/SCS/CI gibi kümelenmiş SAP örnekleri için de kullanılmamalıdır.

SAP örnekleri için otomatik başlatma ile ilgili ek bilgilere buradan bakın:

Daha büyük 3 katmanlı SAP sistemleri

3 katmanlı SAP yapılandırmalarının High-Availability yönleri zaten daha önceki bölümlerde ele alınmıştır. Ancak, DBMS sunucu gereksinimlerinin Azure 'da bulunması için çok büyük olduğu, ancak SAP uygulama katmanı Azure 'a dağıtılabilecek sistemler hakkında ne olur?

3 katmanlı SAP yapılandırmalarının konumu

Uygulama katmanının kendisini veya uygulama ve DBMS katmanını şirket içi ve Azure arasında ayırmak desteklenmez. SAP sistemi, şirket içinde ya da Azure 'da tamamen dağıtılır. Ayrıca, bazı uygulama sunucularının şirket içinde ve başkalarının Azure 'da çalıştırılmasını da desteklemez. Bu, tartışmanın başlangıç noktasıdır. Ayrıca, bir SAP sisteminin ve SAP uygulama sunucusu katmanının iki farklı Azure bölgesinde dağıtılan DBMS bileşenlerine sahip olmak için de destekliyoruz. Örneğin, Orta ABD Batı ABD ve SAP uygulama katmanındaki DBMS. Bu tür yapılandırmaların desteklenmesinin nedeni SAP NetWeaver mimarisinin gecikme süresinin duyarlılığı olur.

Bununla birlikte, geçen yılın veri merkezi iş ortaklarının Azure bölgelerine birlikte ortak konumlar geliştirildiği bir kurs üzerinden. Bu ortak konumlar genellikle bir Azure bölgesindeki fiziksel Azure veri merkezlerine yakın yakındadır. Azure 'a ExpressRoute aracılığıyla ortak konumdaki varlıkların kısa uzaklığı ve bağlantısı, 2 milisaniyeden daha kısa bir gecikme süresine neden olabilir. Böyle durumlarda, bu tür bir ortak konumda DBMS katmanını (depolama SAN/NAS dahil) bulmak için Azure 'daki SAP uygulama katmanı da mümkündür. Hana büyük örnekleri.

SAP sistemlerinin çevrimdışı yedeklemesi

Seçilen SAP yapılandırmasına (2 katmanlı veya 3 katmanlı) bağlı olarak, yedeklemeniz gerekir. VM 'nin içeriği ve veritabanının bir yedeklemesi vardır. DBMS ile ilgili yedeklemelerin veritabanı yöntemleriyle yapılması bekleniyor. Farklı veritabanları için ayrıntılı bir açıklama, DBMS kılavuzundabulunabilir. Diğer yandan, SAP verileri, bu bölümde açıklandığı gibi çevrimdışı bir şekilde (veritabanı içeriği de dahil), sonraki bölümde açıklandığı gibi, çevrimiçi olarak da yedeklenebilir.

Çevrimdışı yedekleme temelde Azure portal aracılığıyla VM 'nin kapatılmasını ve temel VM diskinin bir kopyasını ve VM 'ye eklenen tüm diskleri gerektirir. Bu, sanal makinenin ve ilişkili diskinin bir zaman noktası görüntüsünü korur. yedeklemeleri farklı bir Azure Depolama hesabına kopyalamanız önerilir. bu nedenle, bu belgenin Azure Depolama hesapları arasında diskleri kopyalama bölümünde açıklanan yordam geçerlidir.

bu durumun geri yüklenmesi, temel vm 'nin yanı sıra temel vm 'nin orijinal disklerini ve bağlı disklerin, kaydedilmiş diskleri yönetilen diskler için özgün Depolama hesabına veya kaynak grubuna geri kopyalayarak ve ardından sistemi yeniden dağıtmaya oluşur. Bu makalede, PowerShell 'de bu işlemin nasıl betikleştiribir bir örnek gösterilmektedir: https://www.westerndevs.com/_/azure-snapshots/

Yukarıda açıklanan şekilde bir VM yedeklemesini geri yüklemek için yeni bir SAP lisansı yüklediğinizden emin olun.

SAP sisteminin çevrimiçi yedeklemesi

DBMS yedeklemesi, DBMS Kılavuzu' nda AÇıKLANDıĞı gibi DBMS 'ye özgü yöntemlerle gerçekleştirilir.

SAP sisteminde bulunan diğer VM 'Ler Azure sanal makine yedekleme işlevi kullanılarak yedeklenebilir. Azure sanal makine yedeklemesi, Azure 'da tüm VM 'leri yedeklemek için standart bir yöntemdir. Azure Backup yedeklemeleri Azure 'da depolar ve VM 'nin geri yüklenmesini yeniden sağlar.

Not

Ara 2015 itibariyle, VM yedeklemesini kullanarak SAP lisanslama için kullanılan benzersiz VM KIMLIĞINI değiştirmeyin. Bu, bir VM yedeğinden geri yükleme işleminin, geri yüklenen VM 'nin yeni bir VM olarak kabul edildiği ve önceki bir değişikliği değiştirmediği için yeni bir SAP lisans anahtarı yüklenmesini gerektirdiği anlamına gelir.

Windows logo. Windows

teorik olarak, veritabanlarını çalıştıran vm 'ler tutarlı bir şekilde yedeklenebilir ve örneğin, SQL Server gibi DBMS sisteminin Windows VSS (Birim Gölge Kopyası Hizmeti) desteği de desteklenir https://msdn.microsoft.com/library/windows/desktop/bb968832(v=vs.85).aspx . Ancak, Azure VM yedeklemeleri, veritabanlarının zaman içindeki geri yüklemelerini temel alan mümkün değildir. Bu nedenle, Azure VM yedeklemesi 'ne güvenmek yerine DBMS işlevselliğiyle veritabanlarının yedeklerini gerçekleştirme önerisi.

Azure sanal makine yedeklemesi hakkında bilgi almak için Buradan başlayın: VM ayarlarından bir Azure VM yedekleyin.

diğer olanaklar, bir Azure sanal makinesinde yüklü Microsoft Data Protection Manager birleşimini kullanmak ve veritabanlarını yedeklemek/geri yüklemek için Azure Backup. daha fazla bilgiye buradan ulaşabilirsiniz: System Center DPM ile iş yüklerini Azure 'a yedeklemeye hazırlanma.

Linux logosu. Linux

Linux 'ta Windows VSS ile eşdeğer değildir. Bu nedenle, yalnızca dosya ile tutarlı yedeklemeler mümkündür ancak uygulamayla tutarlı yedeklemeler mümkün değildir. SAP DBMS yedeklemesi, DBMS işlevselliği kullanılarak yapılmalıdır. SAP ile ilgili verileri içeren dosya sistemi, örneğin, burada açıklandığı gibi tar kullanılarak kaydedilebilir: https://help.sap.com/saphelp_nw70ehp2/helpdata/en/d3/c0da3ccbb04d35b186041ba6ac301f/content.htm

Üretim SAP lanlar için Azure as DR sitesi

parçaal 2014 ' den itibaren, hyper-v, System Center ve azure 'daki çeşitli bileşenlere yönelik uzantılar, hyper-v ' d e bağlı olarak şirket içinde çalışan vm 'ler için azure 'u DR sitesi olarak kullanımını etkinleştirir.

Bu çözümün nasıl dağıtılacağını ayrıntılandıran bir blog şurada belgelenmiştir: Azure Site Recovery Ile SAP çözümlerini koruma.

SAP sistemleri için yüksek kullanılabilirlik Özeti

Azure 'da SAP sistemleri için yüksek kullanılabilirliğe ilişkin önemli noktaları şunlardır:

  • Bu noktada, SAP tek hata noktası, şirket içi dağıtımlarda yapılacağından tam olarak aynı şekilde güvenli hale getirilmeyebilir. Bunun nedeni, paylaşılan disk kümelerinin üçüncü taraf yazılım kullanılmadan Azure 'da henüz derlenmemiştir.
  • DBMS katmanı için, paylaşılan disk kümesi teknolojisine bağlı olmayan DBMS işlevlerini kullanmanız gerekir. Ayrıntılar, DBMS kılavuzundabelgelenmiştir.
  • Azure altyapısında veya konak bakımda hata etki alanları içindeki sorunların etkilerini en aza indirmek için Azure kullanılabilirlik kümelerini kullanmanız gerekir:
    • SAP uygulama katmanı için bir kullanılabilirlik kümesi olması önerilir.
    • SAP DBMS katmanı için ayrı bir kullanılabilirlik kümesi kullanılması önerilir.
    • Farklı SAP sistemlerinin VM 'Leri için aynı Kullanılabilirlik kümesinin uygulanması önerilmez.
    • Premium yönetilen diskleri kullanmanız önerilir.
  • SAP DBMS katmanının yedekleme amaçları için, DBMS kılavuzunukontrol edin.
  • SAP Iletişim kutusu örneklerinin yedeklenmesi, basit iletişim kutusu örneklerinin yeniden dağıtılması için genellikle daha hızlı olduğundan biraz daha anlamlı hale gelir.
  • SAP sisteminin genel dizinini içeren VM 'yi yedekleme ve aynı şekilde farklı örneklerin tüm profilleri ile birlikte, Windows Yedekleme olması gerekir ve bu, örneğin, Linux üzerinde tar. Windows server 2008 (r2) ve Windows Server 2012 (r2) arasında farklar olduğundan, daha yeni Windows sunucu sürümleri kullanarak yedeklemeyi daha kolay hale getirir; Windows Server 2012 (r2) Windows konuk işletim sistemi olarak çalıştırılmasını öneririz.

Sonraki adımlar

Makaleleri okuyun: