SAP NetWeaver için Azure Sanal Makineleri planlama ve uygulama

Microsoft Azure, şirketlerin uzun tedarik döngüleri olmadan en kısa zamanda işlem ve depolama kaynakları edinmelerini sağlar. Azure Sanal Makine hizmeti, şirketlerin SAP NetWeaver tabanlı uygulamalar gibi klasik uygulamaları Azure'a dağıtmalarına ve şirket içinde başka kaynaklara sahip olmadan güvenilirlik ve kullanılabilirliklerini genişletmelerine olanak sağlar. Azure Sanal Makine Hizmetleri ayrıca şirketler arası bağlantıları da destekler ve bu sayede şirketler Azure Sanal Makineleri şirket içi etki alanları, Özel Bulutları ve SAP Sistem Ortamı ile etkin bir şekilde tümleştirmektedir. Bu teknik yazı, Microsoft Azure Sanal Makinesi'nin temellerini açıklar ve Azure'da SAP NetWeaver yüklemeleri için planlama ve uygulama konuları hakkında bir adım adım yol gösterir ve bu nedenle, Azure'da SAP NetWeaver'ın gerçek dağıtımlarına başlamadan önce okunan belge olması gerekir. Bu makale, verilen 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ı'nın tamamlayıcılarıdır.

Özet

Bulut Bilişim, küçük şirketlerden büyük ve çok uluslu kuruluşlara kadar BILIŞIM sektöründe daha fazla önem kazanarak yaygın olarak kullanılan bir terimdir.

Microsoft Azure, Microsoft'un Cloud Services platformudur ve çok çeşitli yeni olanaklar sunar. Müşteriler artık uygulamaları bulutta hizmet olarak hızlı bir şekilde s sağlamayı ve sağlamayı geri alamıyor, bu nedenle teknik veya bütçe kısıtlamalarıyla sınırlı değil. Şirketler, donanım altyapısına zaman ve bütçe yatırımı yapmak yerine uygulamaya, iş süreçlerine ve müşteriler ve kullanıcılar için avantajlarına odaklanmaktadır.

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 Microsoft Azure içinde SAP NetWeaver tabanlı uygulamaların tercih platformu olarak nasıl planlan ve uygulandığını açıklar.

Yazının kendisi iki ana yönüne odaklanır:

• İlk bölümde, Azure'da SAP NetWeaver tabanlı uygulamalar için desteklenen iki dağıtım deseni açıklandı. Ayrıca SAP dağıtımları ile Azure'ın genel olarak işlenmesini de açıklar.
• İkinci bölümde, ilk bölümde açıklanan farklı senaryoların uygulanmasıyla ilgili ayrıntılar yer almaktadır.

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

Tanımlar ön

Belge boyunca aşağıdaki terimleri kullanırsınız:

• IaaS: Hizmet Olarak Altyapı
• PaaS: Hizmet Olarak Platform
• SaaS: Hizmet Olarak Yazılım
• SAP Bileşeni: ECC, BW, Çözüm Yöneticisi veya S/4HANA gibi tek bir SAP uygulaması. SAP bileşenleri, geleneksel ABAP veya Java teknolojilerini veya İş Nesneleri gibi NetWeaver olmayan bir tabanlı uygulamayı temel alıyor olabilir.
• SAP Ortamı: Geliştirme, QAS, Eğitim, DR veya Üretim gibi bir iş işlevini gerçekleştirmek için mantıksal olarak gruplu bir veya daha fazla SAP bileşeni.
• SAP Yatay: Bu terim, müşterinin IT ortamının tüm SAP varlıklarını ifade eder. SAP ortamı tüm üretim ortamlarını ve üretim dışı ortamları içerir.
• SAP Sistemi: BIR SAP ERP geliştirme sistemi, SAP BW test sistemi, SAP CRM üretim sistemi gibi DBMS katmanının ve uygulama katmanının birleşimidir. Azure dağıtımlarında, bu iki katmanın şirket içi ile Azure arasında bölünmesi desteklanmaz. Bir SAP sisteminin şirket içinde dağıtılacağı veya Azure'da dağıtılacağı anlamına gelir. Ancak sap ortamının farklı sistemlerini Azure'a veya şirket içine dağıtabilirsiniz. Örneğin, Azure'da SAP CRM geliştirme ve test sistemlerini dağıtabilirsiniz ancak sap CRM üretim sistemi şirket içindedir.
• Şirket içi veya karma: Vm'lerin şirket içi veri merkezleriyle Azure arasında siteden siteye, çok siteli veya ExpressRoute bağlantısı olan bir Azure aboneliğine dağıtılacağı bir senaryoyu açıklar. Yaygın Azure belgelerinde bu tür dağıtımlar, şirket içi ve şirket içi ve hibrit senaryolar olarak da açıklanmıştı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şletmektir. Şirket içi ortamı, aboneliğin Azure varlıklarına genişletildi. 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şebiliyor ve bu VM'lerde (DBMS hizmetleri gibi) hizmetleri çalıştırabilirsiniz. Şirket içinde dağıtılan VM'ler ile Azure tarafından dağıtılan VM'ler arasında iletişim ve ad çözümlemesi mümkündür. Bu, SAP varlıklarının Azure'a dağıtımıyla ilgili en yaygın ve neredeyse özel durumdur. Daha fazla bilgi için bu makaleye ve bu makaleye bakın.
• Azure İzleme Uzantısı, Gelişmiş İzleme ve SAP için Azure Uzantısı: Bir öğeyi ve aynı öğeyi açıklama. Sap Host Agent'a Azure altyapısı hakkında bazı temel veriler sağlamak için sizin tarafından dağıtılması gereken bir VM uzantısını açıklar. SAP notlarında SAP, bunu İzleme Uzantısı veya Gelişmiş izleme olarak ifade etmek olabilir. Azure'da buna SAP için Azure Uzantısı olarak başvururuz.

Kaynaklar

Azure belgelerinde SAP iş yükü için giriş noktası, sanal Kullanmaya başlayın ile Azure üzerinde SAP bulunur. Bu giriş noktasından başlayarak aşağıdaki konuları ele alan birçok makale bulabilirsiniz:

• Azure'da SAP NetWeaver ve Business One
• Azure'da çeşitli DBMS sistemleri için SAP DBMS kılavuzları
• Azure'da SAP iş yükü için yüksek kullanılabilirlik ve olağanüstü durum kurtarma
• Azure'da SAP HANA için özel kılavuz
• SAP HANA DBMS için Azure HANA Büyük Örneklerine özgü kılavuz

Aşağıdaki SAP Notları, aşağıdaki konu başlığıyla Azure üzerinde SAP:

Ayrıca Linux için tüm SAP Notlarını içeren SCN Wiki'lerini okuyun.

Azure aboneliklerinin genel varsayılan sınırlamaları ve maksimum sınırlamaları bu makalede bulunabilir.

Olası Senaryolar

SAP genellikle kuruluşlar içindeki en kritik görev açısından uygulamalardan biri olarak görülür. Bu uygulamaların mimarisi ve işlemleri çoğunlukla karmaşıktır ve kullanılabilirlik ve performans gereksinimlerini karşılamanız önemlidir.

Bu nedenle kuruluşların bu tür iş açısından kritik iş süreçleri için hangi bulut sağlayıcısını seçeceği konusunda dikkatli olması gerekir. Azure, iş açısından kritik SAP uygulamaları ve iş süreçleri için ideal genel bulut platformudur. Çok çeşitli Azure altyapısını kullanarak mevcut SAP NetWeaver ve S/4HANA sistemlerinin neredeyse hepsi bugün Azure'da barındırabilirsiniz. Azure, terabaytlarca bellek ve 200'den fazla CPU ile VM'ler sağlar. Bunun ötesinde Azure, 24 TB'a kadar HANA dağıtımlarının ölçeğinin daha fazla ve 120 TB'a kadar olan SAP HANA dağıtımına olanak sağlayan HANABüyük Örnekleri sunar. Bugün neredeyse tüm şirket içi SAP senaryolarını Azure'da da çalıştırabilirsiniz.

Senaryoların ve bazı desteksiz senaryoların kaba bir açıklaması için Azure sanal makinesi tarafından desteklenen senaryolarda SAP iş yükü belgesine bakın.

Bu senaryoları ve Azure'a dağıtmak istediğiniz mimarinizin plan ve geliştirmesi boyunca başvurulan belgelerde desteklenmiyor olarak adlandırılmış bazı koşulları kontrol edin.

Genel olarak en yaygın dağıtım düzeni, aşağıdaki gibi bir şirket içi ve şirket içi ve şirket içi senaryodur

Birçok müşteri için şirket içi ve şirket içi dağıtım deseni uygulamanın nedeni, tüm uygulamaların şirket içi kullanım verilerini kullanarak Azure'a genişletmenin ve Azure'a sanal veri merkezi olarak davranmanın en Azure ExpressRoute saydam olmasıdır. Azure'a taşınan varlık artmaya devam ettikçe, Azure tarafından dağıtılan altyapı ve ağ altyapısı büyür ve şirket içi varlıklar da buna göre azalır. Kullanıcılar ve uygulamalar için her şey saydamdır.

SAP sistemlerini genel olarak Azure IaaS veya IaaS'ye başarıyla dağıtmak için, geleneksel dış kaynak veya barındırma hizmeti teklifleri ile IaaS teklifleri arasındaki önemli farkları anlamak önemlidir. Geleneksel barındırma veya dış kaynak, altyapıyı (ağ, depolama ve sunucu türü) müşterinin barındırmak istediği iş yüküne uyarlasa da, bunun yerine iş yükünü karakterize etmek ve IaaS dağıtımları için doğru Azure bileşenlerini seçmek müşterinin veya iş ortağının sorumluluğundadır.

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

• Azure VM'lerinde çalıştırarak desteklenen SAP ürünlerini değerlendirme
• Bu SAP ürünleri için belirli Azure VM'lerinde desteklenen belirli İşletim Sistemi yayınlarını değerlendirme
• Belirli Azure VM'leri ile SAP ürünleriniz için desteklenen DBMS yayınlarını değerlendirme
• Bazı gerekli OS/DBMS yayınlarının, desteklenen bir yapılandırmaya almak için SAP sürümü, Destek Paketi yükseltmesi ve çekirdek yükseltmesi gerçekleştirmenizi gerektirip gerektirmeyenleri değerlendirin
• Azure'da dağıtmak için farklı işletim sistemlerine taşımanız gerekip gerekip gerek olmadığını değerlendirin.

Azure'da desteklenen SAP bileşenleri, desteklenen Azure altyapı birimleri ve ilgili işletim sistemi sürümlerini ve DBMS yayınlarını gösteren ayrıntılar, Azure dağıtımları için hangi SAP yazılımının desteklemektedir makalesinde açıklanmıştır. Geçerli SAP yayınlarının, işletim sisteminin ve DBMS yayınlarının değerlendirilmesi sonucunda elde olunan sonuçlar, SAP sistemlerini Azure'a taşıma çabalarını büyük ölçüde etkiler. Bu değerlendirmenin sonuçları, SAP sürüm yükseltmelerinin veya işletim sistemlerinin değişikliklerinin gerekli olduğu durumlarda önemli hazırlık çalışmaları olup olmadığını tanımlar.

Azure Bölgeleri

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

Farklı Azure bölgelerinin listesi için Azure coğrafyaları makalesine bakın. Tüm Azure bölgeleri aynı hizmetleri sunmamaktadır. Çalıştırmak istediğiniz SAP ürününe ve bu ürünle ilgili işletim sistemine ve DBMS'ye bağlı olarak, belirli bir bölgenin ihtiyaç istediğiniz VM türlerini sunmamaktadır. Bu özellikle M/Mv2 VM SAP HANA vm'lere ihtiyacınız olan vm'leri çalıştırmak için özellikle de doğrudur. Bu VM aileleri yalnızca bölgelerin bir alt kümesine dağıtılır. Bölgeye göre kullanılabilir ürünler sitesi yardımıyla hangi VM, türler, Azure depolama türleri veya diğer Azure Hizmetleri'nin hangi bölgelerde kullanılabilir olduğunu bulabilirsiniz. Planlamaya başlarken birincil bölge ve son olarak ikincil bölge olarak belirli bölgeleriniz varsa, önce gerekli hizmetlerin bu bölgelerde kullanılabilir olup olmadığını araştırmanız gerekir.

Kullanılabilirlik Alanları

Azure bölgelerinden birkaçı, Kullanılabilirlik Alanları. Kullanılabilirlik Alanları Azure bölgesi içinde fiziksel olarak ayrı konumlar vardı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, Azure'ın iki Kullanılabilirlik Alanları arasında iki VM dağıtmak ve SAP DBMS sisteminiz veya SAP Central Services için yüksek kullanılabilirlik çerçevesi uygulamak Size Azure'da en iyi SLA'yı sunar. Azure'daki bu sanal makine SLA'sı için, Sanal Makine SLA'larının en son sürümünü kontrol edin. Azure bölgeleri son yıllarda hızla geliştirildi ve genişletildi. Bu nedenle Azure bölgelerinin topolojisi, fiziksel veri merkezlerinin sayısı, bu veri merkezleri arasındaki uzaklık ve Azure Kullanılabilirlik Alanları farklı olabilir. Bu da ağ gecikme süresine neden olur.

Uygulama ilkesi Kullanılabilirlik Alanları HANA Büyük Örnekleri'nin HANA'ya özgü hizmeti için geçerli değildir. HANA Büyük Örnekleri için Hizmet Düzeyi sözleşmelerini, büyük örnekler için SLA makalesinde Azure üzerinde SAP HANA Büyük Örnekleri

Hata Etki Alanları

Hata Etki Alanları, veri merkezlerindeki fiziksel altyapıyla yakından ilgili bir fiziksel hata birimini temsil eder ve fiziksel bir dikey penceresi veya raf bir Hata Etki Alanı olarak kabul edilebilirken, ikisi arasında doğrudan bire bir eşleme yoktur.

Microsoft Azure Virtual Machine Services'de bir SAP sisteminin parçası olarak birden çok Sanal Makine dağıtarak uygulamanızı farklı Hata Etki Alanlarına dağıtarak daha yüksek kullanılabilirlik SLA'ları gereksinimlerini karşılarsınız. Ancak Hata Etki Alanlarının Azure Ölçek Birimi (yüzlerce İşlem düğümü veya Depolama düğümü ve ağ koleksiyonu) üzerinden dağıtılması veya VM'lerin belirli bir Hata Etki Alanına ataması, doğrudan denetime sahip olmadığınız bir işlemdir. Azure yapı denetleyicisini farklı Hata Etki Alanları üzerinde bir VM kümesi dağıtmaya yönlendirecek şekilde, 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 belgenin Azure kullanılabilirlik kümeleri bölümüne bakın.

Etki Alanlarını Yükseltme

Yükseltme Etki Alanları, birden çok VM'de çalışan SAP örneklerinden oluşan bir SAP sistemi içindeki VM'nin nasıl güncelleştirilmiş olduğunu belirlemeye yardımcı olan bir mantıksal birimi temsil eder. Bir yükseltme oluştuğunda, Microsoft Azure Bu Yükseltme Etki Alanlarını tek tek güncelleştirme işleminin üzerinden geçebilirsiniz. VM'leri dağıtım zamanında farklı Yükseltme Etki Alanlarına yayarak SAP sisteminizi kısmen olası kapalı kalma sürelerinden koruyabilirsiniz. Azure'ın farklı Yükseltme Etki Alanlarına yayılmış bir SAP sisteminin VM'lerini dağıtmaya zorlamak için her VM'nin dağıtım zamanında belirli bir öznitelik ayarlamanız gerekir. Hata Etki Alanlarına benzer şekilde, Bir Azure Ölçek Birimi birden çok Yükseltme Etki Alanına ayrılır. Azure yapı denetleyicisini farklı Yükseltme Etki Alanları üzerinde bir VM kümesi dağıtmaya yönlendirecek şekilde, 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 Azure kullanılabilirlik kümeleri bölümüne bakın.

Azure kullanılabilirlik kümeleri

Bir Azure kullanılabilirlik kümesi içindeki Azure Sanal Makineleri, Azure Fabric Denetleyicisi tarafından farklı Hata ve Yükseltme Etki Alanları üzerinden dağıtılır. Farklı Hata ve Yükseltme Etki Alanları üzerinde dağıtımın amacı, bir SAP sisteminin tüm VM'lerinin altyapı bakımı veya bir Hata Etki Alanı içindeki bir hata durumunda kapanmasını önlemektir. Varsayılan olarak, VM'ler bir kullanılabilirlik kümesi kapsamında değildir. Bir VM'nin kullanılabilirlik kümesine katılımı dağıtım zamanında veya daha sonra bir VM'nin yeniden yapılandırılması ve yeniden dağıtımıyla tanımlanır.

Azure kullanılabilirlik kümeleri kavramını ve kullanılabilirlik kümelerinin Hata ve Yükseltme Etki Alanları ile olan ilişkilerini anlamak için bu makaleyi okuyun.

Kullanılabilirlik kümelerini tanımlarken ve bir kullanılabilirlik kümesi içinde farklı VM ailelerinin çeşitli VM'lerini karıştırmaya çalışırken, belirli bir VM türünü bu tür bir kullanılabilirlik kümesine dahil etmeye engel olan sorunlarla karşılaşıp karşılaşıp karşılaşıp karşılaşmanız gerekebilir. Bunun nedeni, kullanılabilirlik kümesi belirli bir işlem konak türünü içeren ölçek birimine bağlı olmasıdır. Ayrıca belirli bir işlem ana bilgisayarı türü yalnızca belirli türdeki VM ailelerini çalıştır olabilir. Örneğin, bir kullanılabilirlik kümesi oluşturmanız ve ilk VM'yi kullanılabilirlik kümesine dağıtmanız ve Esv3 ailesinin bir VM türü seçmeniz ve ardından M ailesinin bir VM'sini ikinci VM olarak dağıtmayı denersanız, ikinci ayırmada reddedilirsiniz. Bunun nedeni, Esv3 ailesi VM'lerinin M ailesinin sanal makineleriyle aynı konak donanımı üzerinde çalışmama nedenidir. Aynı sorun, VM'leri yeniden boyutlandırmaya ve Esv3 ailesinde yer alan bir VM'yi M ailesinin vm türüne taşımaya çalışılırken ortaya çıkabilir. Aynı konak donanımı üzerinde barındırılmayabilecek bir VM ailesine yeniden boyutlandırma durumunda, kullanılabilirlik kümenizin tüm VM'lerini kapatmanız ve bunları diğer konak makine türünde çalıştırılmak 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ı ilkesi, HANA Büyük Örnekleri'nin HANA'ya özgü hizmeti için geçerli değildir. HANA Büyük Örnekleri için Hizmet Düzeyi sözleşmelerini, büyük örnekler için SLA makalesinde Azure üzerinde SAP HANA Büyük Örnekleri.

Eşleştirilmiş Azure bölgeleri

Azure, belirli veri çoğaltmanın bu sabit bölge çiftleri arasında etkinleştirildiğinde Azure Bölge çiftleri sunar. Bölge eşleştirmesi İş sürekliliği ve olağanüstü durum kurtarma (BCDR): Azure Eşleştirilmiş Bölgeleri makalesinde belgelenir. Makalede anlatıldığında, verilerin çoğaltılması, sizin tarafından eşleştirilmiş bölgeye çoğaltılacak şekilde yapılandırılan Azure depolama türlerine bağlanır. Ayrıca ikincil bir bölgede Depolama yedekliliği sağlama makalesine de bakın. Böyle bir çoğaltmaya izin verecek depolama türleri, DBMS iş yükü için uygun olan depolama türleridir. Bu nedenle, Azure depolama çoğaltmanın kullanılabilirliği Azure blob depolama (yedekleme amaçları gibi) veya diğer yüksek gecikme süresine sahip depolama senaryolarıyla sınırlı olacaktır. Eşleştirilmiş bölgeleri ve birincil veya ikincil bölge olarak kullanmak istediğiniz hizmetleri kontrol edinken, birincil bölgenize yönelik Azure hizmetlerinin ve/veya VM türlerinin eşleştirilmiş bölgede kullanılabilir durumda olmadığınız durumlarla karşılaşabilirsiniz. Veya Azure eşleştirilmiş bölgesi veri uyumluluğu nedenleriyle kabul edilemez bir durumla karşılaşabilirsiniz. Bu gibi durumlarda ikincil/olağanüstü durum kurtarma bölgesi olarak eşleştirilmiş olmayan bir bölgeyi kullana ihtiyacınız vardır. Böyle bir durumda, Azure'ın kendi çoğaltılmış olduğu verilerin bir kısmının çoğaltılmasıyla ilgilenmeniz gerekir. Active Directory ve DNS'nizi olağanüstü durum kurtarma bölgenize çoğaltma örneği, Active Directory ve DNS için olağanüstü durum kurtarmayı ayarlama makalesinde açıklanmıştır

Azure sanal makine hizmetleri

Azure, dağıtmayı seçerek çok çeşitli sanal makineler sunar. Ön teknoloji ve altyapı satın almaları 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ı işlem ve depolama sağlayarak uygulamaların bakımını ve işletimini kolaylaştırır. Altyapı yönetimi, çeşitli farklı fiyatlandırma modellerinin seçeneğiyle kullanım ihtiyaçlarını karşılamak için yüksek kullanılabilirlik ve dinamik ölçeklendirme için tasarlanmış bir platformla otomatikleştirilmiştir.

Azure sanal makineler ile Microsoft, özel sunucu görüntülerini IaaS örnekleri olarak Azure 'a dağıtmanızı sağlar. Ya da Azure Marketi 'nden ç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.

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:

• Azure Ayrılmış Sanal Makine Örnekleri nedir?
• Ayrılmış VM Örnekleriyle sanal makine boyutu esnekliği
• Azure rezervasyon indirimini sanal makinelere uygulama

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.

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ı.

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

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

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:

• Standart depolama hesapları için ölçeklenebilirlik hedefleri
• Premium Sayfa Blobu depolama hesapları için ölçeklenebilirlik hedefleri

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.

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.

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

Her Azure Sanal Makinesinin ağ arabirim kartına birden çok IP adresi atanabilir. Bu ikincil IP, gerekirse BIR 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 sanal makinelerin kayan IP'lerinin kullanımı 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:

• Birden çok Windows vm oluşturma
• Birden çok NIC ile Linux VM oluşturma
• Şablon kullanarak çoklu NIC VM'leri dağıtma
• PowerShell kullanarak çoklu NIC VM'leri dağıtma
• Azure CLI kullanarak çoklu NIC VM'leri dağıtma

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, azure'daki bir geliştirme sisteminden şirket içinde dağıtılan bir test sistemine değişiklikleri taşımanız için hem bu sistemlerin çıktısını hem de SAP Transport Management Sistemi'nin (TMS) kullana biliyor olması 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.

• PowerShell kullanarak siteden siteye VPN bağlantısı ile sanal ağ oluşturma
• Siteden Siteye VPN Gateway bağlantıları için VPN cihazları hakkında
• VPN Gateway SSS

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

• Azure portal’ı kullanarak bir sanal ağa yönelik Noktadan Siteye bağlantı yapılandırma
• PowerShell'i kullanarak bir sanal ağa yönelik bir Noktadan Siteye bağlantı yapılandırma

Ç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 iletişimin 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:

• https://azure.microsoft.com/documentation/services/expressroute/
• https://azure.microsoft.com/pricing/details/expressroute/
• https://azure.microsoft.com/documentation/articles/expressroute-faqs/

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

• https://azure.microsoft.com/documentation/articles/expressroute-howto-linkvnet-arm/
• https://azure.microsoft.com/documentation/articles/expressroute-howto-circuit-arm/

Ş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ıtan müşteriler tarafından etkinleştirilir.

Azure ağ Özeti

Bu bölümde, Azure ağı hakkında birçok önemli nokta bulunmaktadır. Ana noktaların özeti aşağıda verilmiştir:

• Azure sanal ağları, Azure dağıtımınıza bir ağ yapısı eklemenize olanak tanır. Sanal ağlar birbirlerine karşı yalıtılabilir veya ağ güvenlik grupları yardımı ile VNET 'ler arasındaki trafik denetlenebilir.
• VM 'lere IP adres aralıkları atamak veya VM 'lere sabit IP adresleri atamak için Azure sanal ağları yararlanılabilir olabilir
• Siteden siteye veya Noktadan siteye bağlantı kurmak 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 hizmetlerindeki kotalar

Depolama ve ağ altyapısının Azure altyapısında çeşitli hizmetler çalıştıran VM 'Ler arasında paylaşıldığından emin olmanız gerekir. Müşterinin kendi veri merkezlerinde olduğu gibi, bazı altyapı kaynaklarından bazılarının sağlanması bir ölçüde gerçekleşecektir. Microsoft Azure platformu, kaynak tüketimini sınırlamak ve tutarlı ve belirleyici performansı korumak için disk, CPU, ağ ve diğer kotaları kullanır. Farklı VM türlerinin (A5, A6, vb.) disk sayısı, CPU, RAM ve ağ için farklı kotalar vardır.

Azure çözümlerinde SAP planlama ve boyutlandırma sırasında, her bir sanal makine boyutu için kotalar göz önünde bulundurulmalıdır. VM kotaları burada (Linux) ve burada (Windows)açıklanmaktadır.

Tanımlanan kotalar teorik en yüksek değerleri temsil eder. Disk başına ıOPS sınırı, küçük g/ç (8 KB) ile sağlanabilir, ancak büyük olasılıkla büyük g/ç (1 MB) ile birlikte ulaşılmayabilir. IOPS sınırı, tek disk ayrıntı düzeyi üzerinde zorlanır.

Bir SAP sisteminin Azure sanal makine Hizmetleri 'ne uygun olup olmadığını veya mevcut bir sistemin Azure üzerinde sistem dağıtmak üzere farklı şekilde yapılandırılması gerekip gerekmediğini belirlemek için kaba bir karar ağacı olarak, aşağıdaki karar ağacının kullanılması gerekir:

1. İle başlamak için en önemli bilgiler, belirli bir SAP sistemine yönelik SAPS gereksinimidir. SAP sistemi 2 katmanlı bir yapılandırmada şirket içinde zaten dağıtılmış olsa bile, SAPS gereksinimlerinin DBMS bölümüne ve SAP uygulama bölümüne ayrılması gerekir. Mevcut sistemlerde, kullanılan donanımla ilgili olan SAPS 'ler, mevcut SAP kıyaslamaları temelinde belirlenebilir veya tahmin edilebilir. Sonuçlar, SAP standart uygulama değerlendirmeleri hakkında sayfasında bulunabilir. Yeni dağıtılan SAP sistemlerinde, sistemin SAPS gereksinimlerini belirleyecek bir boyutlandırma alıştırması yapmanız gerekir.
2. Mevcut sistemlerde, DBMS sunucusunda g/ç birimi ve saniye başına g/ç işlemleri ölçülmelidir. Yeni planlanmış sistemlerde, yeni sistem için boyutlandırma alıştırması, DBMS tarafında g/ç gereksinimlerine ilişkin kaba fikirler de vermelidir. Emin değilseniz, sonunda bir kavram kanıtı uygulamanız gerekir.
3. DBMS sunucusunun SAPS gereksinimini Azure 'un sağladığı farklı VM türleri ile karşılaştırın. Farklı Azure VM türlerinin SAPS 'si ile ilgili bilgiler SAP Note 1928533' de belgelenmiştir. Veritabanı katmanı, dağıtımların çoğunda ölçeklendirolmayan bir SAP NetWeaver sistemindeki katman olduğundan, odak DBMS VM 'sinde olmalıdır. Buna karşılık, SAP uygulama katmanı da genişletilebilir. SAP tarafından desteklenen Azure VM türlerinden hiçbiri gerekli SAPS 'leri sunabiliyorsa, planlı SAP sisteminin iş yükü Azure üzerinde çalıştırılamaz. Sistemi şirket içinde dağıtmanız ya da sistem için iş yükü birimini değiştirmeniz gerekir.
4. burada (Linux) ve burada (Windows)belgelendiği gibi, Azure, standart Depolama veya Premium Depolama kullanmanıza bakılmaksızın disk başına bir ıops kotası uygular. VM türüne bağlı olarak, birbirine bağlanan veri disklerinin sayısı farklılık gösterir. Sonuç olarak, her farklı VM türüyle elde edilebilir maksimum ıOPS numarasını hesaplayabilirsiniz. Veritabanı dosyası düzenine bağlı olarak, Konuk işletim sisteminde tek bir birim olacak şekilde disk şeridi oluşturabilirsiniz. Ancak, dağıtılmış bir SAP sisteminin geçerli ıOPS birimi, Azure 'un en büyük VM türüne ait hesaplanan sınırları aşarsa ve daha fazla bellekle telafi şansı yoksa, SAP sisteminin iş yükü ciddi bir şekilde etkilenebilir. Bu gibi durumlarda, Azure 'da sistemi dağıtmayan bir noktaya basabilirsiniz.
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ı gerekebilir. Bu adımda, SAP uygulama katmanında bir bileşen olup olmadığını denetlemeniz gerekir, bu, genişleme ve farklı Azure VM türleri sunan CPU ve bellek kaynaklarına sığmıyor. Böyle bir bileşen varsa, SAP sistemi ve iş yükü Azure 'a dağıtılamaz. Ancak SAP uygulama bileşenlerini birden çok Azure VM 'ye ölçeklendirebiliyorsanız, sistem Azure 'a dağıtılabilir.

DBMS ve SAP uygulama katmanı bileşenleri Azure VM 'lerinde çalıştırılabiliyorsanız, yapılandırmanın şu şekilde tanımlanması gerekir:

• Azure VM sayısı
• Bireysel bileşenler için VM türleri
• DBMS VM 'de yeterli ıOPS sağlamak için VHD sayısı

Azure varlıklarını yönetme

Azure portal

Azure portal, Azure VM dağıtımlarını yönetmek için üç arabirimden biridir. Görüntülerden VM dağıtımı gibi temel yönetim görevleri, Azure portal aracılığıyla yapılabilir. ayrıca, Depolama hesapların, sanal ağların ve diğer Azure bileşenlerinin oluşturulması ayrıca, Azure portal iyi işleyebileceği görevlerdir. Ancak, VHD 'leri Şirket içinden Azure 'a yükleme veya Azure 'da bir VHD kopyalama gibi işlevler, üçüncü taraf araçlar ya da PowerShell veya CLı aracılığıyla yönetim gerektiren görevlerdir.

Sanal makine örneği için yönetim ve yapılandırma görevlerinin Azure portal içinden mümkündür.

Bir sanal makineyi yeniden başlatma ve kapatma yanında, sanal makine örneği için veri diskleri ekleyebilir, ayırabilir ve oluşturabilir, görüntü hazırlığı örneğini yakalayabilir ve sanal makine örneğinin boyutunu yapılandırabilirsiniz.

Azure portal, VM 'Leri ve diğer birçok Azure hizmetini dağıtmak ve yapılandırmak için temel işlevleri sağlar. Ancak, Azure portal tüm kullanılabilir işlevler kapsamında değildir. Azure portal, şunun 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 daha fazla sayıda sistem dağıtan müşteriler tarafından yaygın olarak benimsenen güçlü ve genişletilebilir bir çerçevedir. PowerShell cmdlet 'lerinin bir masaüstü, dizüstü bilgisayar veya adanmış Yönetim istasyonuna yüklenmesinden sonra, PowerShell cmdlet 'leri uzaktan çalıştırılabilir.

Azure PowerShell cmdlet 'lerinin kullanımı için yerel bir masaüstü/dizüstü bilgisayar etkinleştirme ve bu makaledebunların Azure abonelikleri ile kullanım için nasıl yapılandırılacağı açıklanmaktadır.

Azure PowerShell cmdlet 'lerinin nasıl yükleneceği, güncelleştirilmesi ve yapılandırılacağına ilişkin daha ayrıntılı adımlar, Azure PowerShell modülünü ınstallbölümünde da bulunabilir. Şimdiye kadar müşteri deneyimi, PowerShell 'in sanal makineleri dağıtmak ve VM dağıtımında özel adımlar oluşturmak için kesinlikle daha güçlü bir araçtır. Azure 'da SAP örnekleri çalıştıran tüm müşteriler, Azure portal yönetim görevlerini tamamlamak için PowerShell cmdlet 'lerini kullanıyor ya da Azure 'da dağıtımlarını yönetmek için özel olarak PowerShell cmdlet 'leri kullanıyor. Azure 'a özgü cmdlet 'ler, 2000 'den fazla Windows ilgili cmdlet 'i ile aynı adlandırma kuralını paylaştığından, bu cmdlet 'leri Windows yöneticilerin kullanmasını sağlayan kolay bir görevdir.

Bkz. örnek: 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 belgedeki SAP Için Azure uzantısı bölümüne bakın) yalnızca POWERSHELL veya CLI aracılığıyla yapılabilir. Bu nedenle, Azure 'da SAP NetWeaver sistemi dağıtma veya yönetme sırasında PowerShell veya CLı 'yi ayarlamak ve yapılandırmak zorunludur.

Azure daha fazla işlevsellik sağladığından, cmdlet 'lerin güncelleştirilmesini gerektiren yeni PowerShell cmdlet 'leri eklenecektir. Bu nedenle, https://azure.microsoft.com/downloads/ cmdlet 'lerin yeni bir sürümü için ayda en az bir kez Azure indirme sitesini denetlemek mantıklı olur. Yeni sürüm eski sürümün üzerine yüklenir.

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

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

Linux kullanan ve Azure kaynaklarını yönetmek isteyen müşteriler için bir seçenek olmayabilir. Microsoft, Azure CLı 'yi alternatif olarak sunmaktadır. Azure CLı, Azure platformuyla çalışmaya yönelik bir dizi açık kaynak ve platformlar arası komut sunar. Azure CLı, Azure portal bulunan işlevlerin çoğunu sağlar.

Yükleme, yapılandırma ve Azure görevlerini gerçekleştirmek için CLı komutlarının nasıl kullanılacağı hakkında bilgi için bkz.

• Azure klasik CLI'yi yükleme
• Azure CLı 2,0 'yi yükler
• Azure Resource Manager şablonları ve Azure CLı kullanarak sanal makineleri dağıtma ve yönetme
• Mac, Linux ve Windows için Azure klasik clı 'yi Azure Resource Manager ile kullanın

İlk adımlar bir dağıtımı planlama

Dağıtım planlamadaki ilk adım SAP çalıştırmak için kullanılabilen VM 'Leri denetetmez. İlk adım, zaman alan bir işlemdir, ancak en önemlileri, şirketinizin iş yükünü veya iş sürecini genel buluta dağıtmak için gereken sınır koşullarına göre, şirketinizdeki uyumluluk ve güvenlik ekipleriyle birlikte çalışır. Şirketiniz Azure 'da daha önce başka yazılımlar dağıttıysanız, işlem kolay olabilir. Şirketiniz, yolculuğun başlangıcında daha fazlaysa, belirli SAP verilerinin ve SAP iş işlemlerinin genel bulutta barındırılmasına izin veren sınır koşullarını ve güvenlik koşullarını anlamak için daha büyük tartışmalar yapmanız gerekebilir.

Yararlı yardım olarak Microsoft 'un sağlayabilmesini sağlayacak uyumluluk tekliflerinin bir listesi için Microsoft Uyumluluk tekliflerini işaret edebilirsiniz.

Bekleyen veriler için veri şifreleme veya Azure hizmetindeki diğer şifreleme gibi diğer sorunlar, Azure şifrelemesi 'ne genel bakışbölümünde belgelenmiştir.

Planlamada projenin bu aşamasını daha düşük bir şekilde tahmin etmeyin. Yalnızca bu konunun etrafında anlaşmanız ve kurallarınız varsa, Azure 'da dağıttığınız ağ mimarisini planlama olan bir sonraki adıma gitmeniz gerekir.

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ı öğrenirsiniz. Ek hazırlık yordamlarının yanı sıra Azure'da VHD'lerin ve VM'lerin işlenmesi bu bölümde ele almaktadır.

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

Microsoft Azure VM'leri ve ilişkili diskleri dağıtmak için birden çok yol sunar. Bu nedenle, VM hazırlıkları dağıtım yöntemine bağlı olarak farklı olabileceği için farkları anlamak önemlidir. Genel olarak, aşağıdaki senaryolara göz atarak:

Genelleştirilmiş olmayan bir diskle bir VM'yi şirket içi azure'a taşıma

Belirli bir SAP sistemini şirket içinden Azure'a taşımayı planla. Bu işlem işletim sistemi, SAP Ikili Dosyaları ve DBMS ikili dosyalarını içeren VHD'nin yanı sıra DBMS'nin veri ve günlük dosyalarını içeren VHD'leri Azure'a yükerek yapılabilir. Aşağıdaki 2.senaryonun aksine, konak adını, SAP SID'yi ve SAP kullanıcı hesaplarını şirket içi ortamda yapılandırıldıklarına göre Azure VM'de tutabilirsiniz. Bu nedenle, görüntünün genelleştirmesi gerekli değildir. Şirket içi hazırlık adımları ve genelleştirilmiş olmayan VM'leri veya VHD'leri Azure'a yüklemek için bu belgenin genelleştirilmiş olmayan bir diskiyle bir VM'yi şirket içinde Azure'a taşımaya yönelik hazırlık bölümlerine bakın. Senaryo 3: Azure'da böyle bir görüntüyü dağıtmanın ayrıntılı adımları için Dağıtım Kılavuzu'nda SAP ile genelleştirilmiş olmayan bir Azure VHD'sini kullanarak VM'yi şirket içinde taşıma makalesini okuyun.

Bu kılavuzda ayrıntılı olarak ele almayılacak bir diğer seçenek de SAP NetWeaver Uygulama Sunucularını ve SAP NetWeaver Central Services Azure Site Recovery azure'a çoğaltmak için Azure Site Recovery kullanmaktır. Veritabanı katmanı için Azure Site Recovery yerine HANA Sistem Çoğaltması gibi veritabanına özgü çoğaltma mekanizmaları kullanılması önerilmez. Daha fazla bilgi için Bkz. Şirket içi uygulamalar için olağanüstü durum kurtarma hakkında kılavuzunun SAP'lerini koruma.

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

Işletim sistemi veya DBMS sürümüne özgü düzeltme eki gereksinimleri nedeniyle, Azure Market görüntüleri gereksinimlerinize uymayabilirsiniz. Bu nedenle, daha sonra birkaç kez dağıtılacak kendi özel işletim sistemi/DBMS VM görüntülerinizi kullanarak bir VM oluşturmanız gerekebilir. Böyle bir özel görüntüyü yinelemeye hazırlamak için aşağıdaki öğelerin dikkate alınmalıdır:

Windows

Diğer ayrıntılar için Upload genelleştirilmiş Windows VHD'yi okuyun ve Azure'da yeni VM'ler oluşturmak için kullanın. Windows ayarları (Windows SID ve ana bilgisayar adı gibi) sysprep komutuyla şirket içi VM'de soyutlama/genelleştirilmiştir.

Linux

Bir VHD'nin Azure'a yüklenmek üzere hazırlanması için SUSE, Red Hatveya Oracle Linuxiçin bu makalelerde açıklanan adımları izleyin.

Şirket içi VM'nize (özellikle de 2 Katmanlı sistemler için) SAP içeriği yükledikten sonra, SAP Software Provisioning Manager (SAP Note [1619720)]tarafından desteklenen örnek yeniden adlandırma yordamı aracılığıyla Azure VM'nin dağıtımı sonrasında SAP sistem ayarlarını uyarabilirsiniz. Şirket içi hazırlık adımları ve genelleştirilmiş bir VM'nin Azure'a yüklemesi için bu belgenin SAP için müşteriye özgü bir görüntüyle VM dağıtma ve Şirket içi bir VHD'yi Azure'a yükleme bölümlerine bakın. Azure'da böyle bir görüntüyü dağıtmanın ayrıntılı adımları için Dağıtım Kılavuzu'nun Senaryo 2: SAP için özel görüntü ile VM dağıtma makalesini okuyun.

Vm'yi sanal makineden Azure Market

Vm'nizi dağıtmak için microsoft veya üçüncü taraf tarafından sağlanan bir VM Azure Market kullanmak istersiniz. VM'nizi Azure'da dağıttıktan sonra, SAP yazılımını ve/veya DBMS'yi vm'nizin içine yüklemek için şirket içi ortamda olduğu gibi aynı yönergeleri ve araçları takip edersiniz. Daha ayrıntılı dağıtım açıklaması için Dağıtım Kılavuzu'nun Senaryo 1: SAP için sanal Azure Market vm dağıtma bölümlerine bakın.

AZURE için SAP ile VM'leri hazırlama

VM'leri Azure'a yüklemeden önce, VM'lerin ve VHD'lerin belirli gereksinimleri karşılaya olduğundan emin olun. 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çi azure'a taşıma hazırlığı

Yaygın dağıtım yöntemlerinden biri, bir SAP sistemi çalıştıran mevcut VM'yi şirket içinden Azure'a taşımaktır. Bu VM'nin ve VM'nin SAP sisteminin Azure'da yalnızca aynı ana bilgisayar adı ve muhtemelen aynı SAP SID kullanılarak çalışması gerekir. Bu durumda, VM'nin konuk işletim sistemi birden çok dağıtım için genelleştirilmiş değildir. Şirket içi ağ Azure'a genişletildi ise, vm içinde şirket içinde daha önce kullanılanla aynı etki alanı hesapları bile kullanılabilir.

Kendi Azure VM Disk'inizi hazırlarken gereksinimler:

• Başlangıçta işletim sistemini içeren VHD'nin boyutu yalnızca 127 GB olabilir. Bu sınırlama Mart 2015 sonunda ortadan kaldırılmış oldu. Artık işletim sistemini içeren VHD, barındırılan VHD'ler gibi diğer Azure Depolama 1 TB'a kadar olabilir.
• Sabit VHD biçiminde olmalıdır. VHDx biçimindeki dinamik VHD'ler veya VHD'ler henüz Azure'da desteklenmiyor. PowerShell komutlarını veya CLI'sini kullanarak VHD'yi karşıya yüklerken dinamik VHD'ler statik VHD'lere dönüştürülür
• VM'ye bağlanan ve Azure'da VM'ye yeniden takacak VHD'lerin de sabit bir VHD biçiminde olması gerekir. Veri disklerinin boyut sınırları için bu makaleyi okuyun. PowerShell komutlarını veya CLI'sini kullanarak VHD'yi karşıya yüklerken dinamik VHD'ler statik VHD'lere dönüştürülür
• Yönetici ayrıcalıklarına sahip başka bir yerel hesap ekleyin. Bu hesap Microsoft desteği tarafından kullanılabilir veya VM dağıtılana ve daha uygun kullanıcılar kullanılabilir hale gelene kadar içinde çalıştırılacak hizmetler ve uygulamalar için bağlam olarak atanabilir.
• Belirli bir dağıtım senaryosu için gerekebilecek diğer yerel hesapları ekleyin.

Windows

Bu senaryoda, VM'yi Azure'a yüklemek ve dağıtmak için VM'nin genelleştirilmesi (sysprep) gerekmez. D:\ sürücüsüne emin olun kullanılmaz. Ekli diskler için disk otomatik olarak bağlanmayı bu belgede ekli diskler için otomatik olarak ayarlama bölümünde açıklandığı gibi ayarlayın.

Linux

Bu senaryoda, VM'yi Azure'a yüklemek ve dağıtmak için VM'nin genelleştirilmesi (waagent -deprovision) gerekmez. /mnt/resource kullanılmay olduğundan ve TÜM disklerin uuid aracılığıyla bağlı olduğundan emin olun. işletim sistemi diski için önyükleme girdisi girişinin uuid tabanlı bağlamayı da yansıta olduğundan emin olun.

SAP için müşteriye özgü bir görüntü ile VM dağıtma hazırlığı

Genelleştirilmiş işletim sistemi içeren VHD dosyaları, Azure Depolama Hesapları'nda kapsayıcılarda veya Yönetilen Disk görüntüleri olarak depolanır. Senaryo 2: Dağıtım Kılavuzu'nun SAP'sı için özel bir görüntü ile VM dağıtma bölümünde açıklandığı gibi, VHD veya Yönetilen Disk görüntüsüne dağıtım şablonu dosyalarınıza kaynak olarak başvurarak böyle bir görüntüden yeni bir VM dağıtabilirsiniz.

Kendi Azure VM Görüntülerinizi hazırlarken gereksinimler:

• Başlangıçta işletim sistemini içeren VHD'nin boyutu yalnızca 127 GB olabilir. Bu sınırlama Mart 2015 sonunda ortadan kaldırılmış oldu. Artık işletim sistemini içeren VHD, barındırılan VHD'ler gibi diğer Azure Depolama 1 TB'a kadar olabilir.
• Sabit VHD biçiminde olmalıdır. VHDx biçimindeki dinamik VHD'ler veya VHD'ler henüz Azure'da desteklenmiyor. PowerShell komutlarını veya CLI'sini kullanarak VHD'yi karşıya yüklerken dinamik VHD'ler statik VHD'lere dönüştürülür
• VM'ye bağlanan ve Azure'da VM'ye yeniden takacak VHD'lerin de sabit bir VHD biçiminde olması gerekir. Veri disklerinin boyut sınırları için bu makaleyi okuyun. PowerShell komutlarını veya CLI'sini kullanarak VHD'yi karşıya yüklerken dinamik VHD'ler statik VHD'lere dönüştürülür
• Belirli bir dağıtım senaryosu için gerekebilecek diğer yerel hesapları ekleyin.
• Görüntüde SAP NetWeaver yüklemesi varsa ve ana bilgisayar adının Azure dağıtımının noktasındaki özgün addan yeniden adla yeniden ad kullanılması olasıdır, SAP Software Provisioning Manager DVD'lerinin en son sürümlerini şablona kopyalamanız önerilir. Bu, yeni bir kopya başlatıldıktan hemen sonra değiştirilen konak adını uyarlamak ve/veya dağıtılan VM görüntüsünde SAP sisteminin SID'sini değiştirmek için SAP tarafından sağlanan yeniden adlandırma işlevini kolayca kullanmana olanak sağlar.

Windows

D:\ sürücüsüne emin olun , bu belgede ekli diskler için otomatik olarak bağlanmayı ayarlama bölümünde açıklandığı gibi ekli diskler için disk otomatik olarak ayarlama özelliği kullanılmaz.

Linux

/mnt/resource kullanılmay olduğundan ve TÜM disklerin uuid aracılığıyla bağlı olduğundan emin olun. Işletim sistemi diski için, önyükleme girişinin uuid tabanlı bağlamayı da yansıta olduğundan emin olun.

• SAP GUI (yönetim ve kurulum amaçları için) böyle bir şablona önceden yüklenmiş olabilir.
• Şirket içi ve şirket içi senaryolarda VM'leri başarıyla çalıştırmak için gereken diğer yazılımlar, bu yazılım VM'nin yeniden adlandırılmasıyla birlikte çalışa sürece yüklenemedi.

VM, hedeflenen Azure dağıtım senaryosunda mevcut olmayan hesaplardan/kullanıcılardan yeterince genel olacak ve sonuçta bağımsız olacak şekilde hazırlanırsa, böyle bir görüntüyü genelleştirmenin son hazırlık adımı gerçekleştirildi.

VM'yi genelleştirme

Windows

Son adım, Yönetici hesabıyla bir VM'de oturum açmadır. Yönetici olarak Windows bir komut penceresi açın. %windir%\windows\system32\sysprep dizinine gidin ve sysprep.exe. Küçük bir pencere görüntülenir. Genelleştir seçeneğinin işaretlenmeli (varsayılan seçenek işaretlenmemiştir) ve Kapatma Seçeneği'ni varsayılan 'Yeniden Başlat' olarak 'shutdown' olarak değiştirmek önemlidir. Bu yordam, sysprep işleminin bir VM'nin Konuk işletim sistemi içinde şirket içinde yürütülmektedir. Yordamı Azure'da zaten çalışan bir VM ile gerçekleştirmek için bu makalede açıklanan adımları izleyin.

Linux

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

Vm'leri ve VHD'leri şirket içi ile Azure arasında aktarma

Vm görüntülerini ve disklerini Azure'a yükleme Azure portal, Azure PowerShell cmdlet'lerini veya CLI'yı kullanmalısınız. Bir diğer olasılık da 'AzCopy' aracının kullanımıdır. Araç, VHD'leri şirket içi ile Azure arasında kopyalayıp (her iki yönde de) kullanabilir. Ayrıca VHD'leri Azure Bölgeleri arasında da kopyalayıp kopyalamayı da sağlar. AzCopy indirme ve kullanımı için bu belgelere bakın.

Üçüncü bir alternatif de çeşitli üçüncü taraf GUI odaklı araçlar kullanmaktır. Ancak, bu araçların Azure Sayfa Bloblarını destekleyeneden emin olun. Bizim için Azure Sayfa Blobu deposu kullanmamız gerekir (farklar blok bloblarını, ekleme bloblarını ve sayfa bloblarını anlama konusunda açıklanmıştır). Ayrıca Azure tarafından sağlanan araçlar, karşıya yüklemesi gereken VM'leri ve VHD'leri sıkıştırmada verimlidir. Sıkıştırmada bu verimlilik karşıya yükleme süresini azaltan (şirket içi tesisinden ve hedeflenen Azure dağıtım bölgesinden İnternet'e yönelik karşıya yükleme bağlantısına bağlı olarak değişir) bu önemlidir. Avrupa'dan ABD tabanlı Azure veri merkezlerine vm veya VHD yüklemenin, aynı VM'leri/VHD'leri Avrupa Azure veri merkezlerine yüklemekten daha uzun sürecek olduğu makul bir varsayımdır.

Şirket içi bir VHD'den Azure'a yükleme

Var olan bir VM'yi veya VHD'yi şirket içi ağdan yüklemek için vm veya VHD'nin bu belgenin genelleştirilmiş olmayan bir diskiyle şirket içi sanal makineyi Azure'a taşımaya hazırlanma bölümünde listelenen gereksinimleri karşılaması gerekir.

Böyle bir VM'nin genelleştirilmiş olması GEREKMİYİR ve durum olarak karşıya yük devredilen ve şirket içi tarafında kapatılan VM'nin şekli. Aynı durum, herhangi bir işletim sistemi içeren ek VHD'ler için de aynıdır.

VHD'yi karşıya yükleme ve Azure Disk yapma

Bu durumda, içinde işletim sistemi olan veya olmayan bir VHD'yi karşıya yüklemek ve bir VM'ye veri diski olarak yüklemek veya işletim sistemi diski olarak kullanmak istiyoruz. Bu çok adımlı bir işlemdir

PowerShell

• Bağlan-AzAccount ile aboneliğiniz için oturum açın
• Set-AzContext ve SubscriptionId veya SubscriptionName parametresiyle bağlamınız için aboneliği ayarlama - bkz. Set-AzContext
• Upload Azure Depolama Hesabına Add-AzVhd ile vhd ekleme - bkz. Add-AzVhd
• (İsteğe bağlı) New-AzDisk ile VHD'den Yönetilen Disk oluşturma - bkz. New-AzDisk
• Set-AzVMOSDisk ile yeni bir VM yapılandırmasının işletim sistemi diskini VHD veya Yönetilen Disk olarak ayarlama - bkz. Set-AzVMOSDisk
• New-AzVM ile VM yapılandırmasından yeni bir VM oluşturma - bkz. New-AzVM
• Add-AzVMDataDisk ile yeni bir VM'ye veri diski ekleme - bkz. Add-AzVMDataDisk

Azure CLI

• az login ile aboneliğiniz için oturum açma
• az account set --subscription <subscription name or id > ile aboneliğinizi seçin
• Upload az storage blob upload ile VHD kullanma - bkz. Azure CLI'yı Azure Depolama.
• (İsteğe bağlı) az disk create ile VHD'den Yönetilen Disk oluşturma - bkz. az disk.
• az vm create ve parameter --attach-os-disk ile karşıya yüklenen VHD veya Yönetilen Diski işletim sistemi diski olarak belirten yeni bir VM oluşturun
• az vm disk attach ve --new parametresiyle yeni bir VM'ye veri diski ekleme

Şablon

• Upload PowerShell veya Azure CLI ile VHD'ye
• (İsteğe bağlı) PowerShell, Azure CLI veya powershell ile VHD'den Yönetilen Disk Azure portal
• VM'yi, bu örnek JSON şablonunda gösterildiği gibi VHD'ye başvuran bir JSON şablonuyla veya bu Yönetilen Diskler JSON şablonunda gösterildiği gibi kullanarak dağıtın.

VM Görüntüsünün Dağıtımı

Var olan bir VM'yi veya VHD'yi şirket içi ağdan karşıya yüklemek için, vm veya VHD gibi bir Azure VM görüntüsü olarak kullanmak için bu belgenin SAP'sine özel bir görüntüyle VM dağıtmaya yönelik hazırlık bölümünde listelenen gereksinimleri karşılaması gerekir.

• VM'nizi genelleştirmek için Linux üzerinde sysprep Windows veya waagent -deprovision kullanma - bkz. Windows için Sysprep Teknik Başvurusu veya Linux için bir linux sanal makinesi yakalama ve Linux için Resource Manager şablonu olarak kullanma
• Bağlan-AzAccount ile aboneliğiniz için oturum açın
• Set-AzContext ve SubscriptionId veya SubscriptionName parametresiyle bağlamınız için aboneliği ayarlama - bkz. Set-AzContext
• Upload Azure Depolama Hesabına Add-AzVhd ile vhd ekleme - bkz. Add-AzVhd
• (İsteğe bağlı) New-AzImage ile VHD'den Yönetilen Disk Görüntüsü Oluşturma - bkz. New-AzImage
• Yeni bir VM yapılandırmasının işletim sistemi diskini
  • Set-AzVMOSDisk -SourceImageUri -CreateOption fromImage ile VHD - bkz. Set-AzVMOSDisk
  • Yönetilen Disk Görüntüsü Set-AzVMSourceImage - bkz. Set-AzVMSourceImage
• New-AzVM ile VM yapılandırmasından yeni bir VM oluşturma - bkz. New-AzVM

Azure CLI

• VM'nizi genelleştirmek için Linux üzerinde sysprep Windows veya waagent -deprovision kullanma - bkz. Windows için Sysprep Teknik Başvurusu veya Linux için bir linux sanal makinesi yakalama ve Linux için Resource Manager şablonu olarak kullanma
• az login ile aboneliğiniz için oturum açma
• az account set --subscription <subscription name or id > ile aboneliğinizi seçin
• Upload az storage blob upload ile VHD kullanma - bkz. Azure CLI'yı Azure Depolama.
• (İsteğe bağlı) az image create ile VHD'den Yönetilen Disk Görüntüsü oluşturma - bkz. az image.
• az vm create ve parameter --image ile yüklenen VHD veya Yönetilen Disk Görüntüsünü işletim sistemi diski olarak belirten yeni bir VM oluşturun

Şablon

• VM'nizi genelleştirmek için Linux üzerinde sysprep Windows veya waagent -deprovision kullanma - bkz. Windows için Sysprep Teknik Başvurusu veya Linux için bir linux sanal makinesi yakalama ve Linux için Resource Manager şablonu olarak kullanma
• Upload PowerShell veya Azure CLI ile VHD'ye
• (İsteğe bağlı) PowerShell, Azure CLI veya Azure portal ile VHD'den Yönetilen Disk Görüntüsü Azure portal
• Vm'yi, bu örnek JSON şablonunda gösterildiği gibi görüntü VHD'sini başvuran bir JSON şablonuyla veya bu örnek JSON şablonunda gösterildiği gibi Yönetilen Disk Görüntüsü kullanarak dağıtın.

VHD'leri Yönetilen Diskler şirket içinde indirme

Hizmet Olarak Azure Altyapısı yalnızca VHD'leri ve SAP sistemlerini karşıya yükley olmanın tek yol yolu değildir. SAP sistemlerini Azure'dan şirket içi dünyaya da geri taşıyabilirsiniz.

VHD'leri veya Yönetilen Diskler sırasında etkin olamayabilirsiniz. VM'lere bağlanan diskleri indirirken bile VM'nin kapat ve bırakmalısınız. Yalnızca şirket içinde yeni bir sistem ayarlamak için kullanılacak olan veritabanı içeriğini indirmek istiyorsanız ve azure'daki sistemin hala çalışır durumda olduğu yeni sistemin kurulumu sırasında diske sıkıştırılmış veritabanı yedeklemesi gerçekleştirerek ve işletim sistemini indirmek yerine yalnızca bu diski indirmeniz kabul edilebilirse uzun bir kapalı kalma süresinin önüne geçebilirsiniz temel VM.

PowerShell

• Yönetilen Disk İndirme İlk olarak Yönetilen Diskin temel blobuna erişmeniz gerekir. Ardından, temel alınan blobu yeni bir depolama hesabına kopyalayıp 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>
  

• VHD'yi indirme SAP sistemi durdurulduktan ve VM kapatıldıktan sonra, VHD disklerini şirket içi dünyaya geri indirmek için şirket içi hedefte PowerShell cmdlet'ini Save-AzVhd kullanabilirsiniz. Bunu yapmak için, Azure portal'ın 'depolama Bölümünde' bulabilirsiniz VHD'nin URL'sine ihtiyacınız vardır (Depolama Hesabına ve VHD'nin oluşturulmuş olduğu depolama kapsayıcıya gitmek gerekir) ve VHD'nin nereye kopyalanması gerektiğini bilebilirsiniz.

  Ardından SourceUri parametresini indirilen VHD'nin URL'si olarak, LocalFilePath'i ise VHD'nin fiziksel konumu (adı dahil) olarak tanımlayarak komutundan faydalanabilirsiniz. Komut şöyle olabilir:

  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
  

  cmdlet'inin Save-AzVhd için bkz. Save-AzVhd.

Azure CLI

• Yönetilen Disk İndirme İlk olarak Yönetilen Diskin temel blobuna erişmeniz gerekir. Ardından, temel alınan blobu yeni bir depolama hesabına kopyalayıp 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>"
  

• VHD'yi indirme SAP sistemi durdurulduktan ve VM kapatıldıktan sonra, VHD disklerini şirket içi dünyaya geri indirmek için şirket içi hedefte Azure CLI komutunu _azure storage blob download_ kullanabilirsiniz. Bunu yapmak için, Azure portal'ın 'Depolama Bölümünde' bulabilirsiniz VHD'nin adına ve kapsayıcıya ihtiyacınız vardır (Depolama Hesabına ve VHD'nin oluşturularak depolama kapsayıcısını bulmanız gerekir) ve VHD'nin nereye kopyalanması gerektiğini bilmek gerekir.

  Ardından, indirilecek VHD'nin parametre blobu ve kapsayıcısını tanımlayarak ve hedefi VHD'nin fiziksel hedef konumu (adı dahil) olarak tanımlayarak komutudan faydalanabilirsiniz. Komut şöyle olabilir:

  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 uygulama katmanını destekleyen bir SAP sistemi veya ayrılmış DBMS sunucusu büyük olasılıkla ikili dosyalar veya SAP veritabanının veri ve günlük dosyalarını içeren birkaç disk içerir. Diskleri kopyalama azure işlevselliği veya diskleri yerel diske kaydetmenin Azure işlevselliği, birden çok diskin tutarlı bir şekilde anlık görüntüsünü alan bir eşitleme mekanizmasına sahip değildir. Bu nedenle, aynı VM'ye bağlı olsalar bile kopyalanan veya kaydedilen disklerin durumu farklı olabilir. Bu, farklı disklerde farklı veriler ve günlük dosyaları olması durumunda sonundaki veritabanının tutarsız olduğu anlamına gelir.

Sonuç: SAP sistem yapılandırmasının parçası olan diskleri kopyalamak veya kaydetmek için SAP sistemini durdurmanız ve dağıtılan VM'yi de kapatmanız gerekir. Ancak daha sonra Azure'da veya şirket içinde SAP sisteminin bir kopyasını oluşturmak için diskleri kopyalayıp indirebilirsiniz.

Veri diskleri, Bir Azure Depolama Hesabında VHD dosyaları olarak depolanmış olabilir ve doğrudan bir sanal makineye bağlanabilir veya görüntü olarak kullanılabilir. Bu durumda, VHD sanal makineye bağlanmadan önce başka bir konuma kopyalanır. Azure'da VHD dosyasının tam adı Azure içinde benzersiz olmalıdır. Daha önce de belirtildiği gibi, bu ad üç parçalı bir addır ve şöyledir:

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

Veri diskleri de Yönetilen Diskler. Bu durumda, Yönetilen Disk sanal makineye bağlanmadan ö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

Bu makalede Azure PowerShell VHD kopyalamak için cmdlet'leri kullanabilirsiniz. Yeni bir yönetilen disk oluşturmak için aşağıdaki örnekte gösterildiği gibi New-AzDiskConfig ve New-AzDisk 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

Bir VHD 'YI kopyalamak için Azure CLı 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ı

• https://storageexplorer.com/

Azure Depolama araştırıcılar Professional sürümleri şurada bulunabilir:

• https://www.cerebrata.com/
• https://clumsyleaf.com/products/cloudxplorer

Bir VHD 'nin bir depolama hesabı içindeki kopyası bir işlemdir. Bu işlem yalnızca birkaç saniye sürer (SAN donanımına benzer bir şekilde, yavaş kopyalama ve yazma sırasında kopyalama ile anlık görüntü oluşturma). VHD dosyasının bir kopyasına sahip olduktan sonra, VHD 'nin kopyalarını sanal makinelere eklemek için bir sanal makineye ekleyebilir veya 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 Azure portal gerçekleştirilemiyor. Azure PowerShell cmdlet 'lerini, Azure clı 'yi veya bir üçüncü taraf depolama tarayıcısını kullanabilirsiniz. PowerShell cmdlet 'leri veya clı komutları blob oluşturabilir ve yönetebilir, bu da blob 'ları Depolama hesapları arasında ve Azure aboneliğindeki bölgeler arasında zaman uyumsuz olarak kopyalama imkanını içerir.

PowerShell

Ayrıca, VHD 'leri abonelikler arasında kopyalayabilirsiniz. Daha fazla bilgi için Bu makaleyiokuyun.

PowerShell cmdlet mantığının temel akışı şöyle görünür:

• 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
• Kopyayı ile Başlat

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>

• İle bir döngüde kopyanın durumunu kontrol edin

Get-AzStorageBlobCopyState -Blob <target blob name> -Container <target container name> -Context <variable containing context of target storage account>

• Yukarıda açıklandığı gibi yeni VHD 'yi bir sanal makineye ekleyin.

Örnekler için Bu makaleyebakın.

Azure CLI

• Kopyayı ile Başlat

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>

• Kopyaya sahip bir döngüde hala varsa durumu denetle

az storage blob show --name <target blob name> --container <target container name> --account-name <target storage account name> --account-key <target storage account name>

• Yukarıda açıklandığı gibi yeni VHD 'yi bir sanal makineye ekleyin.

Disk Işleme

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

İdeal olarak, bir VM yapısının ve ilişkili disklerin işlenmesi basit olmalıdır. Şirket içi yüklemelerde, müşteriler bir sunucu yüklemesi yapılandırmak için birçok yol geliştirmiştir.

• DBMS ve/veya SAP 'nin işletim sistemini ve tüm ikililerini içeren bir temel disk. Mart 2015 ' den itibaren, bu disk boyutu 127 GB ile sınırlı önceki kısıtlamalar yerine en fazla 1 TB olabilir.
• SAP veritabanının DBMS günlük dosyasını ve DBMS geçici depolama alanının günlük dosyasını içeren bir veya birden çok disk (DBMS bunu destekliyorsa). Veritabanı günlüğü ıOPS gereksinimleri yüksekse, gereken ıOPS hacmine ulaşmak için birden çok disk oluşturmanız gerekir.
• SAP veritabanının bir veya iki veritabanı dosyasını ve DBMS geçici veri dosyalarını (DBMS bunu destekliyorsa) içeren birçok disk.

Windows

Birçok müşteri sayesinde, örneğin, SAP ve DBMS ikili dosyalarının c:\ ' da yüklü olmadığı durumlarda yapılandırma gördük. işletim sisteminin yüklendiği sürücü. Bunun çeşitli nedenleri vardı, ancak köke geri döndüğünüzde, genellikle sürücülerin küçük ve işletim sistemi yükseltmeleri gereken ek alanı 10-15 yıl önce gerekiyordu. Her iki koşul de bu günler çok sık uygulanmaz. Bugün c:\ Sürücü, büyük birim disklerinde veya VM 'lerde eşlenebilir. Dağıtımların yapısıyla basit kalmasını sağlamak için, Azure 'da SAP NetWeaver sistemleri için aşağıdaki dağıtım modelini izlemeniz önerilir

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

Linux

Linux takas dosyasını Bu makaledeaçıklandığı gibi Linux üzerinde/mnt/mnt/Resource altına yerleştirin. Takas dosyası, Linux Aracısı/etc/waagent.exe yapılandırma dosyasında yapılandırılabilir. Aşağıdaki ayarları ekleyin veya değiştirin:

ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=30720

Değişiklikleri etkinleştirmek için Linux aracısını ile yeniden başlatmanız gerekir

sudo service waagent restart

Önerilen takas dosyası boyutu hakkında daha fazla bilgi için SAP Note 1597355 ' i okuyun

bu disklere yönelik DBMS veri dosyaları ve Azure Depolama türü için kullanılan disk sayısı, ıops gereksinimlerine ve gerekli gecikme süresine göre belirlenir. Tam kotalar Bu makalede (Linux) ve bu makalede (Windows)açıklanmaktadır.

Son iki yıl içinde SAP dağıtımları deneyimi, şu şekilde özetlenebilir bazı derslere sahiptir:

• Mevcut müşteri sistemleri, SAP veritabanlarını temsil eden farklı boyutlardaki veri dosyalarına sahip olabileceğinden, farklı veri dosyalarına yönelik ıOPS trafiği her zaman aynı değildir. Sonuç olarak, veri dosyaları LUN 'larını bunların dışına koymak için birden çok disk üzerinden bir RAID yapılandırması kullanılması daha iyi hale gelir. özellikle Azure standart Depolama bir ıops oranının, DBMS işlem günlüğüne göre tek bir diskin kotasına isabet ettiği durumlar vardı. bu tür senaryolarda, Premium Depolama kullanımı önerilir veya bir yazılım stripe ile birden çok standart Depolama diskini daha da toplayarak bir araya getirin.

Windows

• Azure Sanal Makinelerde SQL Server için performansa yönelik en iyi yöntemler

Linux

• Linux 'ta yazılım RAID yapılandırma
• Azure’da bir a Linux VM üzerinde LVM’yi yapılandırma

• Premium Depolama, özellikle kritik işlem günlüğü yazmaları için önemli ölçüde daha iyi performans gösterir. performansa benzer bir üretim sunması beklenen SAP senaryolarında, Azure Premium Depolama yararlanabilen VM-Series kullanmanız önemle önerilir.

İşletim sistemini içeren diskin ve önerdiğimiz gibi, SAP ve veritabanının (Temel VM) ikili dosyalarının de 127 GB ile sınırlı olduğunu unutmayın. Artık boyutu 1 TB 'ye kadar olabilir. Bu, örneğin SAP Batch iş günlükleri gibi tüm gerekli dosyaları tutmak için yeterli alan olmalıdır.

Özellikle de DBMS VM 'Leri için daha fazla öneri ve daha ayrıntılı bilgi için, DBMS dağıtım kılavuzuna başvurun

Disk Işleme

Çoğu senaryoda SAP veritabanını sanal makineye dağıtmak için ek diskler oluşturmanız gerekir. Bu belgenin SAP dağıtımları için bölüm VM/disk yapısındaki disk sayısı ile ilgili dikkat edilecek noktalar ele alındık. Azure portal, temel VM dağıtıldıktan sonra diskleri eklemek ve ayırmak için izin verir. Diskler, sanal makine çalışır duruma geldiğinde ve durdurulduğunda da eklenebilir/ayrılabilir. Bir disk iliştirilirken, Azure portal boş bir disk veya mevcut bir disk ekleme olanağı sunar. bu zaman içinde bu noktada başka bir sanal makineye bağlı değildir.

Note: diskler, belirli bir zamanda yalnızca bir VM 'ye iliştirilebilir.

yeni bir sanal makinenin dağıtımı sırasında, yönetilen diskleri kullanmak isteyip istemediğinize karar verebilir veya disklerinizi Azure Depolama hesaplarına yerleştirebilirsiniz. Premium Depolama kullanmak istiyorsanız, yönetilen diskleri kullanmanızı öneririz.

Ardından, yeni ve boş bir disk oluşturmak isteyip istemediğinizi ya da daha önce karşıya yüklenen mevcut bir diski seçip sanal makineye şimdi bağlı olup olmayacağını belirlemeniz gerekir.

önemli: ana bilgisayar Önbelleğe Alma Azure standart Depolama kullanmak istemezsiniz. Ana bilgisayar önbelleği tercihini varsayılan değer olan NONE olarak bırakmanız gerekir. Azure Premium Depolama ile, g/ç özelliği genellikle veritabanı veri dosyalarında tipik g/ç trafiği gibi okunmalıdır okuma Önbelleğe Alma etkinleştirmelisiniz. Veritabanı işlem günlük dosyası olması durumunda, önbelleğe alma önerilmez.

Windows

Azure portal veri diski iliştirme

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

Linux

Diskler iliştirilmişse, sanal makinede oturum açmanız ve Bu makalede açıklandığı gibi diskleri başlatmak gerekir

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

Azure Depolama hesabı, g/ç birimi, ıops ve veri hacmi bakımından sonsuz kaynaklar sağlamaz. Genellikle DBMS VM 'Leri bundan en çok etkilendi. Azure Depolama Hesabı birimi sınırının içinde kalmak için dağıtabilirsiniz birkaç yüksek G/Ç birimi VM'niz varsa, her VM için ayrı bir Depolama Hesabı kullanmak en iyisi olabilir. Aksi takdirde, bu VM'leri farklı sanal Depolama hesaplar arasında her bir hesap hesabı sınırına ulaşmayacak şekilde nasıl dengeleyebilirsiniz Depolama gerekir. Daha fazla ayrıntı DBMS Dağıtım Kılavuzunda ele alınmıştır. Ayrıca, bu sınırlamaları saf SAP uygulama sunucusu VM'leri veya sonunda ek VHD'ler gerektirebilir diğer VM'ler için de göz önünde bulundurabilirsiniz. Yönetilen Disk kullanıyorsanız bu kısıtlamalar geçerli değildir. Premium Depolama kullanmayı planlıyorsanız Yönetilen Disk'i kullanmanız önerilir.

Depolama Hesapları için uygun olan başka bir konu, Depolama Hesabı'Depolama VHD'lerin Coğrafi çoğaltmalı olup olmadığıdır. Coğrafi çoğaltma VM düzeyinde değil Depolama hesap düzeyinde etkinleştirilir veya devre dışı bırakılır. Coğrafi çoğaltma etkinleştirilirse, Depolama Hesabı'nın içindeki 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'nin her VHD'sinde yerel olarak çalışır ve bir VM'de birden çok VHD arasında kronolojik sırada I/Os çoğaltmaz. Bu nedenle, temel VM'yi temsil eden VHD ve 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ığını gösterir. I/O'ların yazıldığı sıraylan bağımsız olarak çoğaltılması, coğrafi çoğaltmanın veritabanları birden çok VHD üzerinde dağıtılmış veritabanı sunucuları için değer oluşturmaz. DBMS'ye ek olarak, işlemlerin verileri farklı VHD'lerde yazması veya işlemesi ve değişiklik sırası tutmanın önemli olduğu başka uygulamalar da olabilir. Bu bir gereksinimse Azure'da coğrafi çoğaltma etkinleştirilmemiş olmalıdır. Bir vm kümesi için coğrafi çoğaltmaya ihtiyacınız olup olmadığını veya istediğinize bağlı olarak, ancak başka bir küme için değil, vm'leri ve ilgili VHD'leri coğrafi çoğaltma etkin veya devre dışı bırakılmış farklı Depolama Hesaplarında kategorilere ayırabilirsiniz.

Bağlı diskler için otomatik olarak bağlanmayı ayarlama

Windows

Kendi Görüntüler veya Diskler'den oluşturulan VM'ler için automount parametresini denetlemeli ve büyük olasılıkla ayarlamalısınız. Bu parametrenin ayarı, Azure'da yeniden başlatma veya yeniden uygulama sonrasında VM'nin bağlı/bağlı sürücüleri otomatik olarak yeniden bağlamasına olanak sağlar. parametresi, Microsoft tarafından sağlanan görüntüler için Azure Market.

Otomatik olarak ayarlama amacıyla, komut satırı yürütülebilir dosyasının belgelerini burada diskpart.exe bakın:

• DiskPart Command-Line Seçenekleri
• Otomatik olarak çıkar

Komut Windows penceresinin yönetici olarak açılması gerekir.

Diskler bağlı ise, vm'de oturum açıp disk yöneticisini Windows gerekir. Otomatik bağlantı ekli diskler için otomatik olarak bağlanma bölümünde önerildiğinde etkinleştirilmemişse, yeni >birimin çevrimiçine alınması ve başlatılması gerekir.

Linux

Bu makalede açıklandığı gibi yeni eklenen bir boş diski başlatmalısiniz. Ayrıca /etc/fstab'a yeni diskler eklemeniz gerekir.

Son Dağıtım

Son dağıtım ve tam adımlar, özellikle SAP için Azure Uzantısı'nın dağıtımı için Dağıtım Kılavuzu'ne bakın.

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

SAP GUI kullanarak genel İnternet üzerinden bu SAP sistemlerine bağlanmak istediğiniz senaryolarda aşağıdaki yordamların uygulanması gerekir.

Belgenin devamlarında, şirket içi sistemler ile Azure sistemleri arasında siteden siteye bağlantı (VPN tüneli) veya Azure ExpressRoute bağlantısı olan şirket içi dağıtımlarda SAP sistemlerine bağlanma gibi diğer önemli senaryoyu ele aacağız.

SAP sistemlerine Uzaktan Erişim

Bu Azure Resource Manager, artık eski klasik modelde olduğu gibi varsayılan uç noktalar yoktur. Bir sanal makinenin Azure Resource Manager bağlantı noktaları şu süre boyunca açıktır:

1. Alt ağ veya ağ arabirimi için hiçbir Ağ Güvenlik Grubu tanımlanmamıştır. Azure VM'lerine gelen ağ trafiği, "Ağ Güvenlik Grupları" olarak adlandırılan bir şekilde güvenli hale getirildi. Daha fazla bilgi için bkz. Ağ Güvenlik Grubu (NSG) nedir?
2. Ağ Azure Load Balancer için herhangi bir bağlantı tanımlanmadı

Bu makalede açıklandığı gibi klasik model ve ARM arasındaki mimari farkını bulabilirsiniz.

İnternet üzerinden SAP Sistemi ve SAP GUI bağlantısının yapılandırması

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

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

Sanal makineleriniz üzerinde güvenlik duvarını, SAP sisteminize gelen trafiğe izin verecek şekilde yapılandırmak gerekebilir.

Windows

Varsayılan olarak, Windows Azure tarafından dağıtılan bir VM'nin içindeki Güvenlik Duvarı açıktır. Artık SAP Bağlantı Noktasının açılmasına izin vermelisiniz, aksi takdirde SAP GUI bağlanamayacaktır. Bunu yapmak için:

• Denetim Masası\System and Security\Windows Firewall'Ayarlar.
• Şimdi Gelen Kurallar'a sağ tıklayın ve Yeni Kural'ı seçin.
• Aşağıdaki Sihirbazda yeni bir Bağlantı Noktası kuralı oluşturma tercihi.
• Sihirbazın sonraki adımlarında, ayarı TCP'de bırakın ve açmak istediğiniz bağlantı noktası numarasını yazın. SAP örneği kimliğimiz 00 olduğu için 3200 kullandık. Örneğinizin farklı bir örnek numarası varsa, daha önce örnek numarasına göre tanımlandığı bağlantı noktası açlanmalıdır.
• Sihirbazın sonraki bölümünde Bağlantıya İzin Ver öğesini işaretli bırakmanız gerekir.
• Sihirbazın sonraki adımlarında kuralın Etki Alanı, Özel ve Genel ağ için geçerli olup olmadığını tanımlamanız gerekir. Gerekirse bunu kendi ihtiyaçlarınıza göre ayarlayın. Ancak genel ağ üzerinden SAP GUI ile dışarıdan bağlanarak kuralın genel ağa uygulanması gerekir.
• Sihirbazın son adımlarında kuralı olarak adlar ve Son'a basarak kaydedin.

Kural hemen geçerli olur.

Linux

Çalışma Azure Market Linux görüntüleri iptables güvenlik duvarını varsayılan olarak etkinleştirmez ve SAP sisteminize bağlantı çalışır. iptable'ları veya başka bir güvenlik duvarını etkinleştirdiyseniz, 32xx numaralı bağlantı noktasına gelen tcp trafiğine izin vermek için iptables veya kullanılan güvenlik duvarının belgelerine bakın (burada xx, SAP sisteminizin sistem numarasıdır).

Güvenlik önerileri

SAP GUI, çalışan SAP örneklerinin (bağlantı noktası 32xx) hiçbirine hemen bağlanmaz, ancak önce SAP ileti sunucusu sürecine (bağlantı noktası 36xx) açılan bağlantı noktası üzerinden bağlanır. Geçmişte aynı bağlantı noktası, uygulama örnekleriyle iç iletişim için ileti sunucusu tarafından kullanıldı. Şirket içi uygulama sunucularının Azure'daki bir ileti sunucusuyla yanlışlıkla iletişim kurmasını önlemek için iç iletişim bağlantı noktaları değiştirilebilir. SAP ileti sunucusu ile uygulama örnekleri arasındaki iç iletişimi, proje testi için geliştirme kopyası gibi şirket içi sistemlerden kopyalanmış sistemlerde farklı bir bağlantı noktası numarasıyla değiştirmeniz kesinlikle önerilir. Bu, varsayılan profil parametresiyle yapılabilir:

rdisp/msserv_internal

SAP İleti Sunucusu için güvenlik Ayarlar belgesinde belgelenmiş gibi

SAP NetWeaver tanıtım/eğitim senaryosu ile tek VM

Bu senaryoda, tam eğitim/tanıtım senaryosunun tek bir VM'de yer alan tipik bir eğitim/tanıtım sistemi senaryosu gerçekleştirmektedir. Dağıtımın VM görüntü şablonları aracılığıyla tamamlanır. Ayrıca bu tanıtım/eğitim vm'lerinin birden çok vm'nin aynı adla dağıtılmasının gerektir olduğunu varsayalım. Tüm eğitim sistemlerinin şirket içi varlıklarınıza bağlantısı yok ve karma dağıtımın tam tersi.

Bu belgede VM'leri Azure için SAP ile hazırlama bölümünde açıklandığı gibi bir VM Görüntüsü oluşturduğunuz kabul edildi.

Senaryoyu uygulayan olay dizisi şu şekildedir:

PowerShell

• Her eğitim/tanıtım ortamı için yeni bir kaynak grubu oluşturma

$rgName = "SAPERPDemo1"
New-AzResourceGroup -Name $rgName -Location "North Europe"

• Depolama hesabı kullanmak istemiyorsanız yeni bir depolama hesabı Yönetilen Diskler

$suffix = Get-Random -Minimum 100000 -Maximum 999999
$account = New-AzStorageAccount -ResourceGroupName $rgName -Name "saperpdemo$suffix" -SkuName Standard_LRS -Kind "Storage" -Location "North Europe"

• 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.

# 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

• Sanal makineye İnternet'den erişmek için kullanılan yeni bir genel IP adresi oluşturma

# 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şturma

# 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'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 de tanımlanması gerekir.

#####
# 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ükleyin. Tüm blob adları (bloblara yönelik URL 'Ler) Azure içinde 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. Windows için, yukarıda açıklandığı gibi PowerShell 'i kullanın veya örneği $rgName yerine% rgname% kullanmak üzere uyarlayın ve Windows komut kümesini kullanarak ortam değişkenini ayarlayın.

• Her eğitim/tanıtım dünyası için yeni bir kaynak grubu oluşturun

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ı 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.

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 'ten sanal makineye erişmek için kullanılabilecek yeni bir genel IP adresi oluşturun

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ştur

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 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 de tanımlanması gerekir.

#####
# 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ükleyin. Tüm blob adları (bloblara yönelik URL 'Ler) Azure içinde 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

Örnek şablonları GitHub Azure-QuickStart-Templates deposunda kullanabilirsiniz.

• Basit Linux VM
• basit Windows VM
• Görüntüden VM

Azure içinde iletişim kuran bir VM kümesi uygulama

Bu karma olmayan senaryo, tanıtım/eğitim senaryosunu temsil eden yazılımın birden çok VM 'ye yayıldığı eğitim ve tanıtım amacıyla tipik bir senaryodur. Farklı VM 'lerde yüklenen farklı bileşenlerin birbirleriyle iletişim kurması gerekir. Bu senaryoda, şirket içi ağ iletişimi veya şirket içi bir senaryoya gerek yoktur.

Bu senaryo, bu belgenin SAP NetWeaver demo/eğitim senaryosuyla bölüm tek VM 'de açıklanan yükleme uzantısıdır. Bu durumda, var olan bir kaynak grubuna daha fazla sanal makine eklenecektir. Aşağıdaki örnekte, eğitim yatay bir SAP ASCS/SCS VM 'den, bir DBMS çalıştıran bir VM 'den ve SAP uygulama sunucusu örnek VM 'den oluşur.

Bu senaryoyu oluşturmadan önce, daha önce senaryoda zaten uygulanmış olan temel ayarları düşünmeniz gerekir.

Kaynak grubu ve sanal makine adlandırma

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

Sanal makine adı, kaynak grubu içinde benzersiz olmalıdır.

Farklı VM 'Ler arasında iletişim için ağ kurma

Aynı eğitim/tanıtım çelerine ait klonlarla adlandırma çakışmalarını engellemek için, her yatay için bir Azure sanal ağı oluşturmanız gerekir. DNS ad çözümlemesi, Azure tarafından sağlanacak veya kendi DNS sunucunuzu Azure dışında (burada açıklanmayacak şekilde) yapılandırabilirsiniz. Bu senaryoda, kendi DNS sitemizi yapılandırmayız. Bir Azure sanal ağı içindeki tüm sanal makineler için, ana bilgisayar adları aracılığıyla iletişim etkinleştirilecek.

Yalnızca kaynak grupları değil, eğitim veya tanıtım ağları 'nın sanal ağlar tarafından ayrılması nedenleri:

• SAP yatay ayarı için kendi AD/OpenLDAP gerekir ve bir etki alanı sunucusunun her bir landscapın parçası olması gerekir.
• SAP yatay ayarı, sabit IP adresleriyle çalışması gereken bileşenlere sahiptir.

Azure sanal ağları ve bunların nasıl tanımlanacağı hakkında daha fazla ayrıntı, Bu makaledebulunabilir.

SAP VM 'lerini kurumsal ağ bağlantısıyla dağıtma (Şirket Içi)

SAP Yatayı çalıştırır ve yüksek kaliteli 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 ve Azure IaaS arasında dağıtımı bölmek istiyorsunuz. Temel varsayım, tek bir SAP 'nin içindeki SAP sistemlerinin birbirleriyle ve şirket içinde dağıtılan diğer birçok yazılım bileşeni ile dağıtım formuyla bağımsız olarak iletişim kurması gereken bir diğer yazılım bileşenleriyle iletişim kurmasını sağlar. Ayrıca, SAP GUI veya diğer arabirimlere bağlanan son kullanıcı için dağıtım formu tarafından tanıtılan bir farklılık olmamalıdır. Bu koşullar yalnızca şirket içi Active Directory/OpenLDAP ve DNS hizmetlerinden oluşan siteden siteye/çok siteli bağlantı veya Azure ExpressRoute gibi özel bağlantılar aracılığıyla Azure sistemlerine genişletilmiş olduğunda karşılanır.

SAP yatay senaryosu

Şirket içi veya hibrit senaryosu, aşağıdaki grafiklerde kabaca açıklanabilir:

Minimum gereksinim, tarayıcı erişimi veya Azure hizmetlerine sistem erişimi için VPN tabanlı bağlantılar için SSL/TLS gibi güvenli iletişim protokollerinin kullanılması. Varsayımı, şirketlerin kurumsal ağı ile Azure arasındaki VPN bağlantısını farklı şekilde işlemesinden farklıdır. Bazı şirketler tüm bağlantı noktalarını tekrar açabilir. Bazı diğer şirketler, açılması gereken bağlantı noktalarında kesin olmasını isteyebilir.

Aşağıdaki tabloda, Genel SAP iletişim bağlantı noktaları listelenir. Temel olarak SAP Gateway bağlantı noktasını açmak yeterlidir.

*) nn = SAP örnek numarası

• *) SID = SAP-sistem KIMLIĞI

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 bulabilirsiniz https://scn.sap.com/docs/DOC-17124 . Bu belgeyle, belirli SAP ürünleri ve senaryoları için gereken VPN cihazında adanmış bağlantı noktalarını açabilmelisiniz.

Bu tür bir senaryoya VM 'Leri dağıtmanın 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ında yazdırma

Şirket Içi senaryoda TCP/IP üzerinden yazdırma

Şirket içi TCP/IP tabanlı ağ yazıcılarınızı bir Azure VM 'de ayarlamak, bir VPN siteden siteye tünele veya ExpressRoute bağlantınızın kurulu olduğu varsayıldığında kurumsal ağınızdan aynı genel bir ayardır.

Windows

Bunu yapmak için:

• Bazı ağ yazıcıları, yazıcınızı bir Azure VM 'de ayarlamayı kolaylaştıran bir yapılandırma sihirbazıyla gelir. Yazıcıyla dağıtılan bir sihirbaz yazılımı yoksa, yazıcıyı ayarlamaya yönelik el ile yeni bir TCP/IP yazıcı bağlantı noktası oluşturulması gerekir.
• 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

• 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.

Ş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

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

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:

• SLES https://en.opensuse.org/SDB:Printing_via_SMB_(Samba)_Share_or_Windows_Share
• RHEL veya Oracle Linux https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/system_administrators_guide/index#sec-Starting_Print_Settings_Config

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

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:

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:

• İşlem STMS kullanarak her konumda (Şirket içi ve Azure) bir taşıma etki alanı ayarlayın
• Etki alanlarını bir etki alanı bağlantısıyla bağlayın ve iki etki alanı arasındaki bağlantıyı onaylayın.
• Yapılandırmayı bağlantılı sisteme dağıtın.

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:

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:

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.

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.

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 .

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

• Portal URL 'sini Değiştir
• Varsayılan bağlantı noktası numaralarını, Portal bağlantı noktası numaralarını Değiştir

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.

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 yönetilen diskler kullanan bir SAP NetWeaver sisteminin örnek mimarisi şuna benzeyebilir:

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 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 HA

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.

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.

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

• UNIX sunucu başlatma/durdurma ile birlikte SAP 'yi başlatma/durdurma
• SAP NetWeaver yönetim aracılarını başlatma ve durdurma
• HANA veritabanının otomatik başlamasını etkinleştirme

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 kendisi veya uygulama ile DBMS katmanının şirket içi ile Azure arasında bölünmesi desteklenmiyor. SAP sistemi tamamen şirket içinde veya Azure'da dağıtılır. Bazı uygulama sunucularının şirket içinde, bazılarının ise Azure'da çalışması da desteklanmaz. Bu, tartışmanın başlangıç noktasıdır. Ayrıca bir SAP sisteminin DBMS bileşenlerinin ve SAP uygulama sunucusu katmanının iki farklı Azure Bölgesinde dağıtılmasını da desteklememektedir. Örneğin, Batı ABD'daki DBMS ve sap uygulama katmanı Orta ABD. Bu tür yapılandırmaları desteklemenin nedeni, SAP NetWeaver mimarisinin gecikme süresi duyarlılığıdır.

Ancak, geçen yıl boyunca veri merkezi iş ortakları Azure Bölgeleri için ortak konumlar geliştirdi. Bu ortak konumlar genellikle bir Azure Bölgesi içindeki fiziksel Azure veri merkezlerine yakın olur. ExpressRoute aracılığıyla ortak konumdaki varlıkların Azure'a kısa uzaklığı ve bağlantısı, 2 milisaniyeden kısa bir gecikme süresine neden olabilir. Böyle durumlarda DBMS katmanını (depolama SAN/NAS dahil) bu tür bir ortak konumda bulmak ve Azure'daki SAP uygulama katmanını bulmak 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, bunun için bir geri ihtiyaç olabilir. VM'nin kendi içeriğine ek olarak veritabanının yedeğine sahip olmalıdır. DBMS ile ilgili yedeklemelerin veritabanı yöntemleriyle yapılması beklenir. Farklı veritabanları için ayrıntılı bir açıklama DBMS Kılavuzu'da bulunabilir. Öte yandan SAP verileri, bu bölümde açıklandığı gibi çevrimdışı (veritabanı içeriği de dahil) veya sonraki bölümde açıklandığı gibi çevrimiçi olarak da destek olabilir.

Çevrimdışı yedekleme temel olarak sanal makine aracılığıyla VM'nin Azure portal ve temel VM diskin bir kopyası ile VM'ye bağlı tüm disklerin kapatılmasını gerektirir. Bu, VM'nin ve ilişkili diskin belirli bir noktadaki görüntüsünü korur. Yedeklemeleri farklı bir Azure Depolama Hesabı'Depolama önerilir. Bu nedenle, Bu belgenin Hesaplar bölümünde azure Depolama diskleri kopyalama bölümünde açıklanan yordam geçerli olacaktır.

Bu durumu geri yükleme işlemi, temel VM'nin ve bağlı disklerin özgün disklerinin yanı sıra temel VM'nin ve bağlı disklerin silinmesini, kaydedilen disklerin yönetilen diskler için özgün Depolama Hesabına veya kaynak grubuna kopyalayıp sonra sistemi yenidenploy işlemiyle oluşur. Bu makalede, PowerShell'de bu işlemi betikle nasıl yazabilirim? https://www.westerndevs.com/_/azure-snapshots/

Yukarıda açıklandığı gibi bir VM yedeklemesi geri yüklenirken yeni bir donanım anahtarı oluşturduğundan yeni bir SAP lisansının yüklü olduğundan emin olun.

SAP sisteminin çevrimiçi yedeklemesi

DBMS yedeklemesi, DBMS Kılavuzu'da açıklandığı gibi DBMS'ye özgü yöntemlerle gerçekleştirilir.

SAP sistemi içindeki diğer VM'ler Azure Sanal Makine Yedekleme işlevi kullanılarak yedek olabilir. Azure Sanal Makine Yedekleme, Azure'da tam bir VM'yi yedeklemek için standart bir yöntemdir. Azure Backup Azure'da depolar ve bir VM'nin yeniden geri yüklemesini sağlar.

Üretim SAP sahneleri için DR sitesi olarak Azure

2014'ten bu yana Hyper-V, System Center ve Azure çevresindeki çeşitli bileşenlere uzantılar, Hyper-V tabanlı şirket içinde çalışan VM'ler için Azure'ın DR sitesi olarak kullanımını sağlar.

Bu çözümün nasıl dağıtılası hakkında ayrıntılı bir blog burada açıklanmıştır: SAP ÇözümleriniAzure Site Recovery.

SAP sistemleri için Yüksek Kullanılabilirlik Özeti

Azure'da SAP sistemleri için Yüksek Kullanılabilirlik'in önemli noktaları:

• Bu noktada SAP tek hata noktasının güvenliği, şirket içi dağıtımlarda olduğu gibi tam olarak aynı şekilde güvenlik altına alınamaz. Bunun nedeni, Paylaşılan Disk kümelerinin henüz üçüncü taraf yazılım olmadan Azure'da yapılamamış olmasıdır.
• DBMS katmanı için, paylaşılan disk kümesi teknolojisini kullanmayan DBMS işlevselliğini kullanabilirsiniz. Ayrıntılar DBMS Kılavuzu'nda belgelenmiştir.
• Azure altyapısında veya konak bakımında Hata Etki Alanları içindeki sorunların etkisini en aza indirmek için Azure kullanılabilirlik kümelerini kullanabilirsiniz:
  • SAP uygulama katmanı için bir kullanılabilirlik kümesine sahip olmak önerilir.
  • SAP DBMS katmanı için ayrı bir kullanılabilirlik kümesine sahip olmak önerilir.
  • Farklı SAP sistemlerinin VM'leri için aynı kullanılabilirlik kümesine uygulama önerilmez.
  • Bu Premium Yönetilen Diskler.
• SAP DBMS katmanının Yedekleme amaçları için DBMS Kılavuzu'nun üzerine bakın.
• BASIT iletişim kutusu örneklerinin yeniden daha hızlı bir şekilde yenidend bayılanı olduğu için SAP İletişim Kutusu örneklerinin geri de hiç mantıklı değildir.
• SAP sisteminin genel dizinini ve farklı örneklerin tüm profillerini içeren VM'yi geri yükleme mantıklıdır ve Windows Yedekleme veya örneğin Linux'ta tar ile gerçekleştir yapılmalıdır. Windows Server 2008 (R2) ile Windows Server 2012 (R2) arasında daha yeni Windows Server yayınlarını kullanarak daha kolay bir şekilde desteklene farklılıklar olduğu için, Windows Server 2012 (R2) konuk işletim sistemi olarak Windows çalıştırmayı öneririz.

Sonraki adımlar

Makaleleri okuyun:

• SAP NetWeaver için Azure Sanal Makineler dağıtımı
• SAP iş yükü için Azure Sanal Makineler DBMS dağıtımında dikkat edilmesi gerekenler
• Azure'da SAP HANA altyapı yapılandırmaları ve işlemleri