Aracılığıyla paylaş

SAP NetWeaver için SQL Server Azure Sanal Makineler DBMS dağıtımı

Bu belge, Azure Hizmet Olarak Altyapı'da (IaaS) SAP iş yükü için SQL Server'ı dağıtırken dikkate alınması gereken birkaç farklı alanı kapsar. Bu belgenin önkoşulu olarak bkz. SAP iş yükü için Azure Sanal Makineler DBMS dağıtımıyla ilgili önemli noktalar. Azure'da SAP iş yükü belgelerindeki diğer kılavuzlara da bakın.

Önemli

Bu belgenin kapsamı SQL Server'da Windows sürümüdür. SAP, SQL Server'ın Linux sürümünü SAP yazılımlarından herhangi biriyle desteklemez. Belgede, Microsoft Azure Platformu'nun Hizmet Olarak Platform (PaaS) teklifi olan Microsoft Azure SQL Veritabanı ele alınmıyor. Bu makaledeki tartışma, Azure'ın IaaS özelliğini kullanarak Azure sanal makinelerinde (VM) şirket içi dağıtımlarla bilinen SQL Server ürününü çalıştırma hakkındadır. Bu iki teklif arasındaki veritabanı özellikleri ve işlevleri farklıdır ve birbiriyle karıştırılmamalıdır. Daha fazla bilgi için bkz. Azure SQL Veritabanı.

Genel olarak, Azure IaaS'de SAP iş yükünü çalıştırmak için en son SQL Server sürümlerini kullanmayı düşünmelisiniz. En son SQL Server sürümleri, bazı Azure hizmetleri ve işlevleriyle daha iyi tümleştirme sağlar. Ya da Azure IaaS altyapısındaki işlemleri en iyi duruma getiren değişikliklere sahip olun.

Azure VM'de çalışan SQL Server hakkında genel belgeler şu makalelerde bulunabilir:

Azure VM'de genel SQL Server belgelerinde yapılan tüm içerik ve deyimler SAP iş yükü için geçerli değildir. Ancak, belgeler ilkeler üzerinde iyi bir izlenim sağlar. SAP iş yükü için desteklenmeyen işlevlere bir örnek, FCI kümelemesi kullanımıdır.

IaaS'de devam etmeden önce bilmeniz gereken bazı SQL Server bilgileri vardır:

  • SQL Sürüm Desteği: DESTEKLENEN en düşük SQL Server sürümünün SQL Server 2008 R2 olduğunu belirten SAP Note #1928533 ile bile Azure'da desteklenen SQL Server sürümlerinin penceresi SQL Server'ın yaşam döngüsüyle birlikte dikte edilir. SQL Server 2012 genişletilmiş bakımı 2022'nin ortasında sona erdi. Sonuç olarak, yeni dağıtılan sistemler için geçerli en düşük sürüm SQL Server 2014 olmalıdır. Ne kadar yeni olursa o kadar iyi. En son SQL Server sürümleri, bazı Azure hizmetleri ve işlevleriyle daha iyi tümleştirme sağlar. Ya da Azure IaaS altyapısındaki işlemleri en iyi duruma getiren değişikliklere sahip olun.

  • Azure Market'ten görüntüleri kullanma: Yeni bir Microsoft Azure VM'sini dağıtmanın en hızlı yolu Azure Market'ten bir görüntü kullanmaktır. Azure Market'te en son SQL Server sürümlerini içeren görüntüler vardır. SQL Server'ın zaten yüklü olduğu görüntüler SAP NetWeaver uygulamaları için hemen kullanılamaz. Bunun nedeni, varsayılan SQL Server harmanlamasının bu görüntülere yüklenmiş olmasıdır; bu harmanlama SAP NetWeaver sistemleri için gereken harmanlama ile uyumlu değildir. Bu tür görüntüleri kullanmak için Microsoft Azure Market dışında SQL Server görüntüsü kullanma bölümünde belgelenen adımları gözden geçirin.

  • Tek bir Azure VM'sinde SQL Server çok örnekli destek: Bu dağıtım yöntemi desteklenir. Ancak, özellikle kullandığınız VM türünün ağ ve depolama bant genişliğiyle ilgili kaynak sınırlamalarına dikkat edin. Ayrıntılı bilgileri Azure'daki sanal makineler için boyutlar makalesinde bulabilirsiniz. Bu kota sınırlamaları, şirket içinde uygulayabildiğiniz aynı çok örnekli mimariyi uygulamanızı engelleyebilir. Tek bir VM içindeki kaynakların paylaşımının yapılandırılması ve buna bağlı müdahaleler nedeniyle, tıpkı şirket içi sistemlerde olduğu gibi aynı hususların göz önünde bulundurulması gerekir.

  • Tek bir VM'de tek bir SQL Server örneğinde birden çok SAP veritabanı: Bunlar gibi yapılandırmalar desteklenir. Tek bir SQL Server örneğinin paylaşılan kaynaklarını paylaşan birden çok SAP veritabanı için göz önünde bulundurulacak hususlar, şirket içi dağıtımlar için geçerli olanlarla aynıdır. Belirli bir VM türüne eklenebilen disk sayısı gibi diğer sınırları göz önünde bulundurun. Azure'daki sanal makineler için ayrıntılı Boyutlar belgesinde belirtildiği gibi, belirli VM türlerinin ağ ve depolama kotası sınırları.

Yeni M serisi VM'ler ve SQL Server

Azure, Mv3 ailesi altında birkaç yeni M serisi SKU ailesi yayımladı. Windows Server konuk işletim sisteminde SMT (Hyperthreading) devre dışı bırakılmadan SQL Server 2022 dahil olmak üzere bu ailedeki bazı VM türleri SQL Server için kullanılmamalıdır. Bunun nedeni, 64'ten fazla vCPU ile Windows Server konuk işletim sistemine sunulan NUMA düğümlerinin sayısının SQL Server'ın barındıramayacak kadar büyük olmasıdır. Windows Server konuk işletim sisteminde SMT devre dışı bırakıldığında vCPU sayısı azalır. Bu nedenle, her NUMA düğümünde vCPU sayısı 64'ten azdır. SMT'yi devre dışı bırakma yöntemi, Azure VM'de SMT'yi devre dışı bırakma işlemi açıklanmıştır. Belirli VM türleri şunlardır:

  • M176(d)s_3_v3 - SMT'yi devre dışı bırakın veya alternatif olarak M176bds_4_v3 veya M176bds_4_v3 kullanın
  • M176(d)s_4_v3 - SMT'yi devre dışı bırakın veya alternatif olarak M176bds_4_v3 kullanın
  • M624(d)s_12_v3 - SMT'yi devre dışı bırakın veya alternatif olarak M416ms_v2 kullanın
  • M832(d)s_12_v3 - SMT'yi devre dışı bırakın veya alternatif olarak M416ms_v2 kullanın
  • M832i(d)s_16_v3 - SMT'yi devre dışı bırakın veya alternatif olarak M416ms_v2 kullanın

Not

Yeni M(b)v3 VM türlerinden bazılarında, önbelleğe alınmış okuma Premium SSD v1 depolama alanı kullanımı, okuma önbelleği kullanmadığınızda elde edeceğiniz okuma ve yazma IOPS hızlarının ve aktarım hızının daha düşük olmasını sağlayabilir.

Genel açıklamaya göre, İşletim sistemi, SQL Server yürütülebilir dosyaları ve SAP yürütülebilir dosyaları ayrı Azure disklerine konumlandırılmalı veya yüklenmelidir. Genellikle, SQL Server sistem veritabanlarının çoğu SAP NetWeaver iş yüküyle üst düzeyde kullanılmaz. Bununla birlikte, SQL Server'ın sistem veritabanları, ayrı bir Azure diskinde diğer SQL Server dizinleriyle birlikte olmalıdır. SQL Server tempdb kalıcı olmayan D:\ sürücüsünde veya ayrı bir diskte bulunmalıdır.

  • Sap sertifikalı tüm VM türleriyle (bkz. SAP Notu #1928533), tempdb veriler ve günlük dosyaları, kalıcı olmayan D:\ sürücüsüne yerleştirilebilir.
  • SQL Server'ın yalnızca bir veri dosyasıyla yüklendiği tempdb SQL Server sürümleriyle birden çok tempdb veri dosyası kullanılması önerilir. D:\ sürücü birimlerinin boyut ve özellikler açısından VM türüne göre farklı olduğunu unutmayın. Farklı VM'lerin D:\ sürücüsünün tam boyutları için Azure'da Windows sanal makineleri için boyutlar makalesini gözden geçirin.

Bu yapılandırmalar, sistem sürücüsünün sağlayabileceklerinden daha fazla alan ve saniyede daha fazla G/Ç işlemi (IOPS) ve depolama bant genişliği tüketmeyi sağlar tempdb . Kalıcı olmayan D:\ sürücüsü de daha iyi G/Ç gecikme süresi ve aktarım hızı sunar. Uygun tempdb boyutu belirlemek için mevcut sistemlerdeki tempdb boyutları kontrol edebilirsiniz.

Not

Veri dosyalarını ve günlük dosyalarını oluşturduğunuz D:\ sürücüsündeki bir klasöre yerleştirirseniz tempdb , vm yeniden başlatıldıktan sonra klasörün mevcut olduğundan emin olmanız gerekir. D:\ sürücüsü vm yeniden başlatıldıktan sonra yeni başlatılabildiğinden, tüm dosyalar ve dizin yapıları silinebilir. SQL Server hizmetinin başlamasından önce D:\ sürücüsünde son dizin yapılarını yeniden oluşturma olasılığı, SQL Server TempDB ve Arabellek Havuzu Uzantılarını depolamak için Azure VM'lerinde SSD'leri kullanma başlığı altında açıklanmıştır.

SQL Server ile SAP veritabanını çalıştıran, tempdb veri ve tempdb günlük dosyalarının D:\ sürücüsüne yerleştirildiği ve Azure Premium Depolama v1 veya v2 üzerinde çalışan bir VM yapılandırması şöyle görünecektir:

SQL Server için basit sanal makine disk yapılandırması diyagramı.

Diyagramda basit bir durum gösterilir. SAP iş yükü, Azure depolama türü, sayısı ve disklerin boyutu için Azure Sanal Makineler DBMS dağıtımıyla ilgili önemli noktalar makalesinde belirtildiği gibi farklı faktörlere bağlıdır. Ancak genel olarak aşağıdakileri öneririz:

  • SQL Server veri dosyalarını içeren tek bir büyük birim kullanarak daha küçük ve orta aralıklı dağıtımlar için. Bu yapılandırmanın ardındaki neden, SQL Server veri dosyalarının aynı boş alana sahip olmadığı durumlarda farklı G/Ç iş yükleriyle ilgilenmenin daha kolay olmasıdır. Büyük dağıtımlarda, özellikle de müşterinin Azure'da SQL Server'a heterojen veritabanı geçişiyle taşındığı dağıtımlarda ayrı diskler kullandık ve ardından veri dosyalarını bu disklere dağıttık. Bu mimari yalnızca her disk aynı sayıda veri dosyası olduğunda, tüm veri dosyaları aynı boyutta olduğunda ve kabaca aynı boş alana sahip olduğunda başarılı olur.
  • Performans yeterince iyi olduğu sürece D:\ sürücüsünü tempdb kullanın. Genel iş yükünün tempdb performansı D:\ sürücüsünde sınırlıysa, tempdb bölümünde önerilen şekilde Azure Premium Depolama v1 veya v2 ya da Ultra Disk'e geçmeniz gerekir.

SQL Server orantılı doldurma mekanizması, tüm SQL Server veri dosyalarının aynı boyutta olması ve aynı serbestlik hızına sahip olması koşuluyla okuma ve yazmaları tüm veri dosyalarına eşit olarak dağıtır. SQL Server'da SAP, okuma ve yazma işlemleri tüm kullanılabilir veri dosyalarına eşit olarak dağıtıldığında en iyi performansı sunar. Veritabanında çok az veri dosyası varsa veya mevcut veri dosyaları yüksek oranda dengesizse, düzeltmenin en iyi yöntemi R3load dışarı aktarma ve içeri aktarma işlemidir. R3load dışa aktarma ve içe aktarma işlemi kesinti süresini içerir ve yalnızca çözülmesi gereken belirgin bir performans sorunu varsa yapılmalıdır. Veri dosyaları yalnızca orta düzeyde farklı boyutlardaysa, tüm veri dosyalarını aynı boyuta yükseltin ve SQL Server zaman içinde verileri yeniden dengelemeye çalışıyor. İzleme bayrağı 1117 ayarlanırsa veya izleme bayrağı olmadan SQL Server 2016 veya üzeri kullanılırsa, SQL Server veri dosyalarını otomatik olarak eşit olarak büyütür.

M Serisi VM'ler için dikkat edilmesi gerekenler

Azure M Serisi VM'de, Azure Yazma Hızlandırıcısı kullanılırken işlem günlüğüne yazma gecikme süresi Azure Premium Depolama performansı v1 ile karşılaştırıldığında azaltılabilir. Sağlanan premium depolama v1'in gecikme süresi, SAP iş yükünün ölçeklenebilirliğini sınırlandırıyorsa, SQL Server işlem günlüğü dosyasını depolayan disk, Yazma Hızlandırıcı ile etkin hale getirilebilir. Ayrıntılar Belge Yazma Hızlandırıcısı'nda okunabilir. Azure Yazma Hızlandırıcısı, Azure Premium Depolama v2 ve Ultra Disk ile çalışmaz. Her iki durumda da gecikme süresi Azure Premium Depolama v1'in sunmasından daha iyidir. Yazma Hızlandırıcısı Azure Premium SSD v2'i desteklemiyor.

Not

Yeni M(b)v3 VM türlerinden bazılarında, önbelleğe alınmış okuma Premium SSD v1 depolama alanı kullanımı, okuma önbelleği kullanmadığınızda elde edeceğiniz okuma ve yazma IOPS hızlarının ve aktarım hızının daha düşük olmasını sağlayabilir.

Diskleri biçimlendirme

SQL Server için, SQL Server verilerini ve günlük dosyalarını içeren diskler için NTFS blok boyutu 64 KB olmalıdır. D:\ sürücüsünü biçimlendirmeye gerek yoktur. Bu sürücü önceden biçimlendirilmiş olarak gelir.

Veritabanlarının geri yüklenmesinin veya oluşturulmasının, dosyaların içeriğini sıfırlayarak veri dosyalarını başlatmasını önlemek için, SQL Server hizmetinin çalıştığı kullanıcı bağlamının Kullanıcı Hakkı Gerçekleştirme toplu bakım görevlerine sahip olduğundan emin olun. Daha fazla bilgi için bkz . Veritabanı anlık dosya başlatma.

Veritabanı Dosyalarını doğrudan Azure Blob Depolama'da depolama

SQL Server 2014 ve sonraki sürümleri, veritabanı dosyalarını çevrelerindeki bir VHD'nin 'sarmalayıcısı' olmadan doğrudan Azure Blob Store'da depolama olanağını açar. Bu işlevsellik, yıllar önce Azure blok depolamasının eksikliklerini gidermeye yönelikti. Bu günlerde, bu dağıtım yönteminin kullanılması ve bunun yerine gereksinimlere bağlı olarak Azure Premium Depolama v1 veya v2 ya da Ultra Disk'i seçmeniz önerilmez.

SQL Server için yedekleme ve kurtarma konusunda dikkat edilmesi gerekenler

SQL Server'ı Azure'a dağıttığınızda yedekleme mimarinizi gözden geçirmeniz gerekir. Sistem bir üretim sistemi olmasa bile SQL Server SAP veritabanının düzenli aralıklarla yedeklenmesi gerekir. Azure Depolama üç kopya tuttuğundan, bir depolama hatasını telafi etme açısından yedekleme eskisi kadar önemli değildir. Yedekleme ve kurtarma planını doğru bir şekilde korumanın öncelikli nedeni, belirli bir noktadan kurtarma işleviyle mantıksal veya manuel hataları telafi etmek açısından önemlidir. Amaç, veritabanını belirli bir noktaya geri yüklemek için yedeklemeleri kullanmaktır. Alternatif olarak, Azure'daki yedekleri kullanarak mevcut veritabanı yedeklemesini kopyalayarak başka bir sistemi başlatabilirsiniz.

Azure'da SQL Server veritabanlarını yedeklemenin ve geri yüklemenin birkaç yolu vardır. En iyi genel bakışı ve ayrıntıları almak için Azure VM'lerinde SQL Server için yedekleme ve geri yükleme belgesini okuyun. Makale çeşitli olasılıkları kapsar.

Microsoft Azure Market'ten SQL Server görüntüsü kullanma

Microsoft, SQL Server sürümlerini içeren Azure Market'te VM'ler sunar. SQL Server ve Windows lisansları gerektiren SAP müşterileri için bu görüntüleri kullanmak, SQL Server'ın zaten yüklü olduğu VM'leri döndürerek lisans gereksinimini karşılama fırsatı olabilir. SAP için bu tür görüntüleri kullanmak için aşağıdaki noktaların yapılması gerekir:

  • SQL Server'in deneme sürümü dışındaki sürümleri, Azure Marketplace'ten dağıtılan 'sadece Windows' sanal makinelerden daha yüksek maliyetlidir. Fiyatları karşılaştırmak için bkz. Windows Sanal Makineler Fiyatlandırması ve SQL Server Enterprise Sanal Makineler Fiyatlandırması.
  • Yalnızca SAP'nin yazılımları için desteklediği SQL Server sürümlerini kullanabilirsiniz.
  • Azure Market'te sunulan VM'lere yüklenen SQL Server örneğinin harmanlanması, SAP NetWeaver için SQL Server örneğinin çalıştırılmasını gerektiren harmanlama değildir. Ancak harmanlamayı aşağıdaki bölümdeki yönergelerle değiştirebilirsiniz.

Microsoft Windows SQL Server VM'sinin SQL Server harmanlamasını değiştirme

Azure Market'teki SQL Server görüntüleri, SAP NetWeaver uygulamaları için gereken harmanlamayı kullanacak şekilde ayarlanmadığından, dağıtımdan hemen sonra değiştirilmesi gerekir. SQL Server için bu harmanlama değişikliği, VM dağıtılır dağıtılmaz ve bir yönetici dağıtılan VM'de oturum açabildiği anda aşağıdaki adımlarla yapılabilir:

  • Yönetici olarak bir Windows Komut Penceresi açın.
  • Dizini C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012 olarak değiştirin.
  • Şu komutu yürüt: Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2
    • <local_admin_account_name> , galeri aracılığıyla VM'yi ilk kez dağıtırken yönetici hesabı olarak tanımlanan hesaptır.

İşlem yalnızca birkaç dakika sürmelidir. Adımın doğru sonucu alıp vermediğinden emin olmak için aşağıdaki adımları gerçekleştirin:

  • SQL Server Management Studio'yu açın.
  • Bir Sorgu Penceresi açın.
  • Komutu SQL Server master veritabanında sp_helpsort çalıştırın.

İstenen sonuç şöyle görünmelidir:

Latin1-General, binary code point comparison sort for Unicode Data, SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data

Sonuç farklıysa, dağıtımı DURDURUN ve kurulum komutunun neden beklendiği gibi çalışmadığını araştırın. SAP NetWeaver uygulamalarının, belirtilenden farklı SQL Server kod sayfalarına sahip bir SQL Server örneğinde dağıtılması, NetWeaver dağıtımları için DESTEKLENMEMEKTEDİR.

Azure'da SAP için SQL Server Yüksek Kullanılabilirliği

SAP için Azure IaaS dağıtımlarında SQL Server'ı kullanarak, veritabanı katmanını yüksek oranda kullanılabilir olarak dağıtmak için ekleyebileceğiniz birkaç farklı olanak vardır. Azure, aşağıdakini kullanarak tek bir VM için farklı up-time SLA'ları sağlar:

  • Farklı Azure blok depolama alanları
  • Azure Kullanılabilirlik Kümesinde dağıtılan bir vm çifti
  • Azure Kullanılabilirlik Alanları arasında dağıtılan bir VM çifti

Üretim sistemleri için, iki kullanılabilirlik alanında esnek düzenleme ile bir sanal makine ölçek kümesi içinde bir çift VM dağıtmanızı bekliyoruz. Daha fazla bilgi edinmek için bkz. SAP iş yükü için farklı dağıtım türlerini karşılaştırma. Bir VM etkin SQL Server Örneğini çalıştırır. Diğer VM pasif örneği çalıştırır.

Windows Genişleme Dosya Sunucusu veya Azure paylaşılan diski kullanarak SQL Server Kümeleme

Microsoft, Windows Server 2016 ile Depolama Alanları Doğrudan kullanıma sunulmuştur. Depolama Alanları, Doğrudan Dağıtım temelinde SQL Server FCI kümeleme genel olarak desteklenir. Azure ayrıca Windows kümeleme için kullanılabilecek Azure paylaşılan diskleri de sunar. SAP iş yükü için bu HA seçeneklerini desteklemiyoruz.

SQL Server günlük gönderimi

SQL Server log shipping, yüksek kullanılabilirlik işlevlerinden biridir. HA yapılandırmasına katılan VM'lerin çalışan ad çözümlemesi varsa, sorun yoktur. Azure'daki kurulum, günlük aktarımı ve ilgili ilkeler açısından yerinde yapılan kurulumdan farklı değildir. SQL Server günlük gönderiminin ayrıntıları, Günlük Gönderimi Hakkında (SQL Server) makalesinde bulunabilir.

SQL Server günlük gönderim işlevi, tek bir Azure bölgesinde yüksek kullanılabilirlik elde etmek için Azure'da neredeyse hiç kullanılmadı. Ancak aşağıdaki senaryolarda, SAP müşterileri Azure'da log shipping yöntemini başarıyla kullanıyorlardı:

  • Bir Azure bölgesinden başka bir Azure bölgesine Olağanüstü Durum Kurtarma senaryoları
  • Azure bölgesine yerel ortamlardan Olağanüstü Durum Kurtarma yapılandırması
  • Şirket içinden Azure'a geçiş senaryoları. Bu gibi durumlarda log shipping, Azure'daki yeni veritabanı dağıtımını şirket içinde devam eden üretim sistemiyle eş zamanlamak için kullanılır. Kesinti sırasında üretim kapatılır ve son ve en son işlem günlüğü yedeklemelerinin Azure veritabanı dağıtımına aktarılması sağlanır. Ardından Azure veritabanı dağıtımı üretim için açılır.

SQL Server AlwaysOn

Always On, şirket içi SAP için desteklenir (bkz. SAP Note #1772688) ve Azure'da SAP ile birlikte desteklenir. SQL Server Kullanılabilirlik Grubu Dinleyicisi'ni dağıtmayla ilgili bazı özel noktalar vardır (Azure Kullanılabilirlik Kümesi ile karıştırılmamalıdır). Bu nedenle, farklı yükleme adımları gereklidir.

Kullanılabilirlik Grubu Dinleyicisi'nin kullanılmasıyla ilgili dikkat edilmesi gereken bazı noktalar şunlardır:

  • Kullanılabilirlik Grubu Dinleyicisi'ni kullanmak yalnızca Windows Server 2012 ve sonraki sürümlerde VM'nin konuk işletim sistemi olarak mümkündür. Windows Server 2012 için, Windows Server 2008 R2 ve Windows Server 2012 tabanlı Microsoft Azure sanal makinelerinde SQL Server Kullanılabilirlik Grubu Dinleyicilerinin uygulandığından emin olun.
  • Windows Server 2008 R2 için bu düzeltme eki yoktur. Bu durumda Always On'un Veritabanı Yansıtma ile aynı şekilde kullanılması gerekir. SAP default.pfl parametresi dbs/mss/server aracılığıyla yapıldığı gibi bağlantı dizesinde bir yük devretme iş ortağı belirterek. Bkz. SAP Notu #965908.
  • Kullanılabilirlik Grubu Dinleyicisi'ni kullanarak Veritabanı VM'lerini ayrılmış bir Load Balancer'a bağlamanız gerekir. Her Zaman Açık yapılandırmasında bu VM'lerin ağ arabirimlerine statik IP adresleri atamanız gerekir. Statik IP adresi tanımlama, Statik özel IP adresiyle VM oluşturma başlığında açıklanmıştır. DHCP ile karşılaştırıldığında statik IP adresleri, her iki VM'nin de durdurulabileceği durumlarda yeni IP adreslerinin atanmasını engelliyor.
  • WSFC küme yapılandırması oluşturulurken, kümenin özel bir IP adresi atanmasını gerektiren özel adımlar vardır. Azure, geçerli işlevselliğiyle küme adını, kümenin oluşturulduğu düğümle aynı IP adresini atar. Bu davranış, kümeye farklı bir IP adresi atamak için el ile bir adım gerçekleştirilmesi gerektiği anlamına gelir.
  • Kullanılabilirlik Grubu Dinleyicisi Azure'da, Kullanılabilirlik grubunun birincil ve ikincil çoğaltmalarını çalıştıran VM'lere atanan TCP/IP uç noktalarıyla oluşturulacak.
  • ACL'ler ile bu uç noktaların güvenliğini sağlamanız gerekebilir.

Azure VM'lerde SQL Server ile Always On dağıtımı hakkında ayrıntılı belgeler şu şekilde sıralanır:

Not

Azure sanal makinelerinde SQL Server Always On kullanılabilirlik gruplarına giriş bölümünde SQL Server'ın Doğrudan Ağ Adı (DNN) dinleyicisi hakkında bilgi edineceksiniz. DNN işlevi SQL Server 2019 CU8 ile kullanıma sunulmuştur. Bu yeni işlevsellik, Kullanılabilirlik Grubu Dinleyicisi'nin sanal IP adresini işleyen bir Azure yük dengeleyicinin kullanımını kullanımdan kaldırıyor.

SQL Server Always On, SAP iş yükü dağıtımları için Azure'da kullanılan en yaygın yüksek kullanılabilirlik ve olağanüstü durum kurtarma işlevidir. Müşterilerin çoğu tek bir Azure Bölgesinde yüksek kullanılabilirlik için Always On kullanır. Dağıtım yalnızca iki düğümle sınırlıysa, bağlantı için iki seçeneğiniz vardır:

  • Kullanılabilirlik Grubu Dinleyicisi'ni kullanma. Kullanılabilirlik Grubu Dinleyicisi ile bir Azure yük dengeleyici dağıtmanız gerekir.

  • Azure yük dengeleyicisi yerine Doğrudan Ağ Adı (DNN) dinleyicisi kullanılabilir. DNN, azure yük dengeleyici kullanma gereksinimini ortadan kaldırıyor ve bu da şunlar için geçerlidir:

    • SQL Server 2016 SP3

      • Windows Server 2016'da daha yeni SQL Server sürümleri

    • SQL Server 2017 CU 25

    • SQL Server 2019 CU8

SQL Server Veritabanı Yansıtma'nın bağlantı parametrelerinin kullanılması yalnızca diğer iki yöntemle ilgili sorunların araştırılması sırasında dikkate alınmalıdır. Bu durumda SAP uygulamalarının bağlantısını her iki düğüm adının da adlandırıldığı şekilde yapılandırmanız gerekir. Bu tür bir SAP yan yapılandırmasının tam ayrıntıları SAP Note #965908 belgelenmiştir. Bu seçeneği kullanarak Kullanılabilirlik Grubu dinleyicisini yapılandırmanız gerekmez. Ve Azure yük dengeleyici olmadan, bu bileşenlerle ilgili sorunları araştırabilir. Ancak unutmayın, bu seçenek yalnızca Kullanılabilirlik Grubunuzu iki örneğe yayılacak şekilde kısıtlarsanız çalışır.

Müşterilerin çoğu, Azure bölgeleri arasında olağanüstü durum kurtarma işlevselliği için SQL Server Always On işlevini kullanıyor. Birkaç müşteri de ikincil çoğaltmadan yedekleme gerçekleştirme özelliğini kullanır.

SQL Server Saydam Veri Şifrelemesi

Birçok müşteri SAP SQL Server veritabanlarını Azure'da dağıtırken SQL Server Saydam Veri Şifrelemesi (TDE) kullanıyor. SAP, SQL Server TDE işlevselliğini tam olarak destekler. Bkz. SAP Notu #1380493.

SQL Server TDE uygulama yapma

Şirket içinde çalışan başka bir veritabanından Azure'da çalışan Windows SQL Server'a heterojen geçiş gerçekleştirdiğiniz durumlarda, SQL Server'da boş hedef veritabanınızı önceden oluşturmanız gerekir. Sonraki adım olarak bu boş veritabanına SQL Server TDE işlevselliğini uygulayacaksınız. Bu sırada gerçekleştirmek istemenizin nedeni, boş veritabanını şifreleme işleminin uzun sürebileceğidir. SAP içeri aktarma işlemleri daha sonra kapalı kalma süresi boyunca verileri şifrelenmiş veritabanına aktarır. Şifrelenmiş bir veritabanına içeri aktarmanın ek yükü, aşağı aktarma aşamasındaki dışarı aktarma aşamasından sonra veritabanını şifrelemekten çok daha düşük bir zaman etkisine sahiptir. Veritabanının üzerinde çalışan SAP iş yüküyle TDE uygulanmaya çalışılırken olumsuz deneyimler yaşanmıştı. Bu nedenle öneri, TDE dağıtımını belirli bir veritabanında SAP iş yükü olmadan veya düşük bir iş yüküyle yapılması gereken bir etkinlik olarak ele almaktır. SQL Server 2016'dan itibaren, ilk şifrelemeyi gerçekleştiren TDE taramasını durdurabilir ve sürdürebilirsiniz.

SAP SQL Server veritabanlarını şirket içinden Azure'a taşıdığınızda şifrelemenin en hızlı uygulandığı altyapıyı test etmenizi öneririz. Bu durumda, şu olguları aklınızda bulundurun:

  • Veritabanına veri şifrelemesi uygulamak için kaç iş parçacığının kullanıldığını tanımlayamazsınız. İş parçacığı sayısı büyük ölçüde SQL Server verilerinin ve günlük dosyalarının dağıtıldığı disk birimi sayısına bağlıdır. Ayrı birimlerin sayısı arttıkça (sürücü harfleri), şifrelemeyi gerçekleştirmek için daha fazla iş parçacığı paralel olarak devreye girer. Bu tür bir yapılandırma, Azure VM'lerindeki SQL Server veritabanı dosyaları için bir veya daha az sayıda depolama alanı oluşturmayla ilgili önceki disk yapılandırma önerileriyle çelişmektedir. Birkaç birimi olan bir yapılandırma, şifrelemeyi yürüten birkaç iş parçacığına yol açabilir. Tek bir iş parçacığı şifrelemesi 64 KB'lık kapsamları okur, şifreler ve ardından işlem günlüğü dosyasına bir kayıt yazarak kapsamın şifrelendiğini söyler. Sonuç olarak işlem günlüğündeki yük orta düzeydedir.
  • Eski SQL Server sürümlerinde, SQL Server veritabanınızı şifrelediğinizde yedekleme sıkıştırmasının verimliliği azalıyordu. Bu davranış, planınız ŞIRKET içi SQL Server veritabanınızı şifrelemek ve ardından Azure'daki veritabanını geri yüklemek için Azure'a bir yedekleme kopyalamak olduğunda bir soruna dönüşebilir. SQL Server yedekleme sıkıştırması, 4 kat sıkıştırma oranına ulaşabilir.
  • SQL Server 2016 ile SQL Server, şifrelenmiş veritabanlarının hem de verimli bir şekilde yedeklenmesinin sıkıştırılmasına olanak tanıyan yeni işlevler kullanıma sunulmuştur. Bazı ayrıntılar için bu bloga bakın.

Azure Key Vault'ı Kullanma

Azure, şifreleme anahtarlarını depolamak için bir Key Vault hizmeti sunar. Diğer taraftaki SQL Server, TDE sertifikaları için depo olarak Azure Key Vault'un kullanılmasına yönelik bir bağlayıcı sunar.

SQL Server TDE için Azure Key Vault listelerini kullanma hakkında daha fazla ayrıntı:

Önemli

SQL Server TDE'yi özellikle Azure Key Vault ile kullandığınızda, SQL Server 2014, SQL Server 2016 ve SQL Server 2017'nin en son düzeltme eklerini kullanmanız gerekir. Bunun nedeni, müşteri geri bildirimlerine göre koda iyileştirmelerin ve düzeltmelerin uygulanmasıdır. Örnek olarak KBA #4058175'a bakın.

En düşük dağıtım yapılandırmaları

Bu bölümde, SAP iş yükü altındaki farklı veritabanları boyutları için bir dizi minimum yapılandırma öneririz. Bu boyutların iş yükünüz için uygun olup olmadığını değerlendirmek çok zordur. Bazı durumlarda, veritabanı boyutuyla karşılaştırıldığında bellek konusunda cömert olabiliriz. Diğer tarafta, disk boyutlandırması bazı iş yükleri için çok düşük olabilir. Bu nedenle, bu yapılandırmalar oldukları gibi ele alınmalıdır. Bunlar, size başlangıç noktası vermesi gereken yapılandırmalardır. Belirli iş yükünüz ve maliyet verimliliği gereksinimlerinize göre ince ayar yapmaya yönelik yapılandırmalar.

Veritabanı boyutu 50 GB ile 250 GB arasında olan küçük bir SQL Server örneği için yapılandırma örneği şöyle görünebilir:

Yapılandırma Veritabanı VM'si Açıklamalar
VM Türü E4s_v3/v4/v5 (4 vCPU/32 GiB RAM)
Hızlandırılmış Ağ Etkinleştir
SQL Server sürümü SQL Server 2019 veya daha yeni
Veri dosyası sayısı 4
Günlük dosyalarının sayısı 1
Geçici veri dosyalarının sayısı SQL Server 2016'dan bu yana, varsayılan 4'tür.
İşletim sistemi Windows Server 2019 veya daha yeni
Disk birleştirme İsterseniz Depolama Alanları
Dosya sistemi NTFS
Blok boyutunu biçimlendir 64 KB
# ve veri disklerinin türü Premium depolama v1: 2 x P10 (RAID0)
Premium depolama v2: 2 x 150 GiB (RAID0) - varsayılan IOPS ve aktarım hızı veya eşdeğer Premium SSD v2		 Premium depolama v1 için önbellek yalnızca okunabilir durumda
# ve günlük disklerinin türü Premium depolama v1: 1 x P20
Premium depolama v2: 1 x 128 GiB - varsayılan IOPS ve aktarım hızı veya eşdeğer Premium SSD v2		 Önbellek = YOK
SQL Server maksimum bellek parametresi Fiziksel RAM'in %90'ını Tek örnek varsayma

Örneğin, bu yapılandırma SQL Server'da SAP Business Suite'in Veritabanı VM yapılandırmasıdır. Bu VM, yıllık geliri 200 BIN ABD dolarının üzerinde ve 200 binden fazla tam zamanlı çalışanı olan küresel bir şirketin tek global SAP Business Suite örneğinin 30 TB veritabanını barındırır. Sistem, Kuzey Amerika bordrosu da dahil olmak üzere farklı alanlarda tüm finansal işleme, satış ve dağıtım işlemlerini ve daha birçok iş sürecini yürütür. Sistem, veritabanı VM'leri olarak Azure M serisi VM'leri kullanarak 2018'in başından beri Azure'da çalışmaktadır. Yüksek kullanılabilirlik nedeniyle sistem, aynı Azure bölgesindeki başka bir Kullanılabilirlik Alanında zaman uyumlu bir çoğaltmayla Always On kullanıyor. Ve Azure'un farklı bir bölgesinde asenkron bir çoğaltma daha. NetWeaver uygulama katmanı en son D(a)/E(a) VM ailelerine dağıtılır.

Yapılandırma Veritabanı VM'si Açıklamalar
VM Türü M192dms_v2 (192 vCPU/4.196 GiB RAM)
Hızlandırılmış Ağ Etkinleştirildi
SQL Server sürümü SQL Server 2019
Veri dosyası sayısı 32
Günlük dosyalarının sayısı 1
Geçici veri dosyalarının sayısı 8
İşletim sistemi Windows Server 2019
Disk birleştirme Depolama Alanları
Dosya sistemi NTFS
Blok boyutunu biçimlendir 64 KB
# ve veri disklerinin türü Premium depolama v1: 16 x P40 veya eşdeğer Premium SSD v2 Önbellek = Yalnızca Okunabilir
# ve günlük disklerinin türü Premium depolama v1: 1 x P60 veya eşdeğer Premium SSD v2 Yazma Hızlandırıcısı Kullanma
# ve disk türü tempdb Premium depolama v1: 1 x P30 veya eşdeğer Premium SSD v2 Önbelleğe alma yok
SQL Server maksimum bellek parametresi Fiziksel RAM'in %95'i

Azure'da SAP için Genel SQL Server Özeti

Bu kılavuzda birçok öneri vardır ve Azure dağıtımınızı planlamadan önce bunu birden çok kez okumanızı öneririz. Genel olarak, Azure'a özgü en iyi SQL Server önerilerini izlediğinden emin olun:

  • Azure'da en fazla avantaja sahip sql server 2022 gibi en son SQLServer sürümünü kullanın.
  • Veri dosyası düzenini ve Azure kısıtlamalarını dengelemek için Azure'da SAP sistem ortamınızı dikkatlice planlayın:
    • Çok fazla diskiniz yok, ancak gerekli IOPS'nize ulaşabildiğinizden emin olmak için yeterli diske sahip olun.
      • Yalnızca daha yüksek bir aktarım hızı elde etmeniz gerekiyorsa diskler arasında şeritleme yapın.
  • Kalıcı olmadığından D:\ sürücüsüne hiçbir zaman yazılım yüklemeyin veya kalıcılık gerektiren dosyaları koymayın. Windows yeniden başlatma veya VM yeniden başlatma sırasında bu sürücüdeki her şey kaybolabilir.
  • Veritabanı verilerini çoğaltmak için SQL Server AlwaysOn çözümünüzü kullanın.
  • Her zaman Ad Çözümleme'yi kullanın, IP adreslerine güvenmeyin.
  • SQL Server TDE kullanarak en son SQL Server düzeltme eklerini uygulayın.
  • Azure Market'ten SQL Server görüntülerini kullanırken dikkatli olun. SQL Server'ı kullanıyorsanız, üzerine herhangi bir SAP NetWeaver sistemi yüklemeden önce örnek harmanlamasını değiştirmeniz gerekir.
  • Dağıtım Kılavuzu'nda açıklandığı gibi Azure için SAP Konak İzleme'yi yükleyin ve yapılandırın.
  • Last updated on