SAP NetWeaver için SQL Server Azure Sanal Makineler DBMS dağıtımı
Bu belge, Azure IaaS'de SAP iş yükü için SQL Server'ı dağıtırken göz önünde bulundurulacak birkaç farklı alanı kapsar. Bu belgenin önkoşulu olarak, Sap iş yükü için Azure Sanal Makineler DBMS dağıtımı ile ilgili önemli noktalar belgesini ve Azure'daki SAP iş yükü belgelerindeki diğer kılavuzları okuyun.
Ö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. Belge, Microsoft Azure Platformu'nun Bir Hizmet Olarak Platform teklifi olan Microsoft Azure SQL Veritabanı tartışmıyor. Bu makaledeki tartışma, Azure Sanal Makineler'da şirket içi dağıtımlar için bilinen SQL Server ürününü çalıştırma ve Azure'ın Hizmet Olarak Altyapı özelliğinden yararlanma 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 Sanal Makineler'de (VM) çalışan SQL Server hakkında genel belgeler şu makalelerde bulunabilir:
- Azure Sanal Makineler'da SQL Server (Windows)
- Windows SQL Server IaaS Aracısı uzantısıyla yönetimi otomatikleştirme
- Azure VM'lerinde SQL Server için Azure Key Vault tümleştirmesini yapılandırma (Resource Manager)
- Kontrol listesi: Azure VM’lerinde SQL Server için en iyi yöntemler
- Depolama: Azure VM'lerinde SQL Server için en iyi performans uygulamaları
- HADR yapılandırması en iyi yöntemleri (Azure VM’leri üzerinde SQL Server)
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 yakın 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 görüntüleri kullanma: Yeni bir Microsoft Azure VM'sini dağıtmanın en hızlı yolu Azure Market bir görüntü kullanmaktır. Azure Market 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üklenmesidir ve SAP NetWeaver sistemleri için gereken harmanlamanın değil. 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'de bulunan kaynakların paylaşılması yapılandırması ve müdahalesi nedeniyle, şirket içiyle aynı konuların dikkate alınması 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ının dikkate alınması gerekenler, şirket içi dağıtımlarla aynıdır. Belirli bir VM türüne eklenebilen disk sayısı gibi diğer sınırları göz önünde bulundurun. Veya Azure'daki sanal makineler için ayrıntılı Boyutlar olarak 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, Windows Server konuk işletim sistemine sunulan VE 64'ten büyük vCPU'ları olan 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 burada 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.
SAP ile ilgili SQL Server dağıtımları için VM/VHD yapısıyla ilgili öneriler
Genel açıklama olan İşletim sistemi, SQL Server yürütülebilir dosyaları uyarınca SAP yürütülebilir dosyaları ayrı Azure diskleri bulunmalıdır 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, deneyimsiz D:\ sürücüsünde veya ayrı bir diskte bulunmalıdır.
- Sap sertifikalı tüm VM türleriyle (bkz. SAP Not #1928533), tempdb verileri ve günlük dosyaları, kalıcı olmayan D:\ sürücüsüne yerleştirilebilir.
- SQL Server'ın tempdb'yi yalnızca bir veri dosyasıyla yüklediği SQL Server sürümleriyle birden çok tempdb veri dosyasının 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 tempdb'nin sistem sürücüsünün sağlayabildiğinden daha fazla alan ve saniyede daha fazla G/Ç işlemi (IOPS) ve depolama bant genişliği tüketmesini sağlar. Kalıcı olmayan D:\ sürücüsü de daha iyi G/Ç gecikme süresi ve aktarım hızı sunar. Uygun tempdb boyutunu belirlemek için mevcut sistemlerde tempdb boyutlarını de kontrol edebilirsiniz.
Not
tempdb veri dosyalarını ve günlük dosyasını oluşturduğunuz D:\ sürücüsündeki bir klasöre yerleştirmeniz durumunda, bir VM yeniden başlatıldıktan sonra klasörün var olduğundan emin olmanız gerekir. Bir VM yeniden başlatıldıktan sonra D:\ sürücüsü yeni başlatılabildiğinden tüm dosya ve dizin yapıları silinebilir. SQL Server hizmetinin başlatılmasından önce D:\ sürücüsünde son dizin yapılarını yeniden oluşturma olasılığı bu makalede belgelenmiştir.
SQL Server'ı SAP veritabanıyla çalıştıran ve tempdb verilerinin ve tempdb logfile dosyasının D:\ sürücüsüne yerleştirildiği ve Azure premium depolama v1 veya v2'nin şöyle görüneceği bir VM yapılandırması:
Diyagramda basit bir servis talebi görüntülenir. 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. Böyle bir 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 tempdb için D:\drive kullanın. Genel iş yükünün D:\ sürücüsünde bulunan tempdb performansı sınırlıysa, tempdb'yi bu makalede önerilen şekilde Azure premium depolama v1 veya v2 ya da Ultra disk'e taşımanız 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ışarı aktarma ve içeri aktarma işlemi kapalı kalma 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 özel
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 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ısı için etkinleştirilebilir. 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ı 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.
SQL Server 2014 ve daha yeni SQL Server sürümleri - Veritabanı Dosyalarını doğrudan Azure Blob 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öntemini kullanmanız ve bunun yerine Azure premium depolama v1, premium depolama v2 veya Ultra disk seçmeniz önerilmez. Gereksinimlere bağlıdır.
SQL Server için Yedekleme/Kurtarma ile ilgili 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 üç görüntü tuttuğundan, depolama kilitlenmesini telafi etme konusunda yedekleme artık daha az önemlidir. Doğru yedekleme ve kurtarma planını korumanın öncelikli nedeni, mantıksal/el ile yapılan hataları telafi etmek için belirli bir noktaya kurtarma işlevi 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 kopyalayan başka bir sistem de kullanabilirsiniz.
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 dışında bir SQL Server görüntüsü kullanma
Microsoft, SQL Server sürümlerini içeren Azure Market 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 değerlendirme dışı sürümleri, Azure Market dağıtılan 'Yalnızca Windows' VM'sinden daha yüksek maliyetler alır. Fiyatları karşılaştırmak için bkz. Windows Sanal Makineler Fiyatlandırması ve SQL Server Enterprise Sanal Makineler Fiyatlandırması.
- Yalnızca SAP tarafından yazılımları için desteklenen SQL Server sürümlerini kullanabilirsiniz.
- Azure Market sunulan VM'lere yüklenen SQL Server örneğinin harmanlanması, SAP NetWeaver'ın SQL Server örneğinin çalıştırılmasını gerektirmemesidir. 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 SQL Server görüntüleri, SAP NetWeaver uygulamaları için gerekli olan 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.
- SQL Server ana veritabanında komut sp_helpsort yürütür.
İ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 SQL Server örneğine dağıtımı NetWeaver dağıtımları için DESTEKLENMEZ .
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, farklı Azure blok depolama alanları, Bir Azure kullanılabilirlik kümesinde dağıtılan vm çifti veya Azure Kullanılabilirlik Alanları dağıtılan bir vm çifti kullanarak tek bir VM için farklı çalışma zamanı SLA'ları sağlar. Ü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 için bkz . SAP iş yükü için farklı dağıtım türlerinin karşılaştırması. 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
Yüksek kullanılabilirlik işlevlerinden biri SQL Server günlük gönderimidir. HA yapılandırmasına katılan VM'lerin çalışan ad çözümlemesi varsa, sorun yoktur. Azure'daki kurulum, günlük gönderimini ayarlamayla ve günlük gönderimi ile ilgili ilkelerle ilgili olarak şirket içinde yapılan hiçbir 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 ile günlük gönderimini başarılı bir şekilde kullanıyordu:
- Bir Azure bölgesinden başka bir Azure bölgesine Olağanüstü Durum Kurtarma senaryoları
- Şirket içinden Azure bölgesine Olağanüstü Durum Kurtarma yapılandırması
- Şirket içinden Azure'a geçiş senaryoları. Bu gibi durumlarda günlük gönderimi, Azure'daki yeni veritabanı dağıtımını şirket içinde devam eden üretim sistemiyle eşitlemek 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 desteklendiğinden (bkz. SAP Note #1772688), 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, bazı 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 veya üzeri bir sürümle 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 Dinleyicilerini etkinleştirme güncelleştirmesinin 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. Bağlantı dizesinde bir yük devretme iş ortağı belirterek (SAP default.pfl parametresi dbs/mss/server aracılığıyla yapılır - 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 işlemi bu makalede 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.
- Geçerli işlevselliğine sahip Azure, küme adını kümenin oluşturulduğu düğümle aynı IP adresini atayacağından, kümenin atanması gereken WSFC küme yapılandırmasını oluştururken gereken özel adımlar vardır. 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'lerinde SQL Server ile Always On dağıtımıyla ilgili ayrıntılı belgeler:
- Azure sanal makinelerinde SQL Server AlwaysOn kullanılabilirlik gruplarına giriş.
- Farklı bölgelerdeki Azure sanal makinelerinde Always On kullanılabilirlik grubu yapılandırın.
- Azure'da Always On kullanılabilirlik grubu için yük dengeleyici yapılandırın.
- HADR yapılandırması en iyi yöntemleri (Azure VM’leri üzerinde SQL Server)
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. Bu yeni işlev 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.
- SQL Server 2016 SP3, SQL Server 2017 CU 25 veya SQL Server 2019 CU8 veya daha yeni SQL Server sürümleriyle Windows Server 2016 veya sonraki sürümlerde Azure yük dengeleyici yerine Doğrudan Ağ Adı (DNN) dinleyicisini kullanabilirsiniz. DNN, azure yük dengeleyici gereksinimini ortadan kaldırıyor.
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 bu azure yük dengeleyici olmadan ve bu, 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. SQL Server TDE işlevselliği SAP tarafından tam olarak desteklenir (bkz. SAP Notu #1380493).
SQL Server TDE uygulama
Ş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. Belge Saydam Veri Şifrelemesi (TDE) komutu ve ayrıntıları açıklar.
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. Daha fazla ayrı birim (sürücü harfi), şifrelemeyi gerçekleştirmek için paralel olarak daha fazla iş parçacığının devreye girdiği anlamına gelir. 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 önerisiyle biraz çelişiyor. 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 uzantıyı 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ı artık verim almamıştı. 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. faktörün 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ı:
- Azure VM'lerinde SQL Server (Resource Manager) için Azure Key Vault tümleştirmesini yapılandırın.
- Müşterilerden SQL Server Saydam Veri Şifrelemesi – TDE + Azure Key Vault hakkında daha fazla soru.
Önemli
ÖZELLIKLE Azure Key Vault ile SQL Server TDE kullanıldığında SQL Server 2014, SQL Server 2016 ve SQL Server 2017'nin en son düzeltme eklerinin kullanılması önerilir. 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 | |
# of data files | 4 | |
# of log files | 1 | |
# of temp data files | SQL Server 2016'dan bu yana 4 veya varsayılan | |
İşletim sistemi | Windows Server 2019 veya daha yeni | |
Disk toplama | İ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 |
Önbellek = Premium depolama v1 için Salt Okunur |
# 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 en fazla bellek parametresi | Fiziksel RAM'in %90'ını | Tek örnek varsayma |
Daha küçük bir SAP Business Suite sistemi gibi veritabanı boyutu 250 GB ile 750 GB arasında olan bir yapılandırma örneği veya küçük bir SQL Server örneği şöyle görünebilir:
Yapılandırma | Veritabanı VM'si | Açıklamalar |
---|---|---|
VM Türü | E16s_v3/v4/v5 (16 vCPU/128 GiB RAM) | |
Hızlandırılmış Ağ | Etkinleştir | |
SQL Server sürümü | SQL Server 2019 veya daha yeni | |
# of data files | 8 | |
# of log files | 1 | |
# of temp data files | SQL Server 2016'dan bu yana 8 veya varsayılan | |
İşletim sistemi | Windows Server 2019 veya daha yeni | |
Disk toplama | İsterseniz Depolama Alanları | |
Dosya sistemi | NTFS | |
Blok boyutunu biçimlendir | 64 KB | |
# ve veri disklerinin türü | Premium depolama v1: 4 x P20 (RAID0) Premium depolama v2: 4 x 100 GiB - 200 GiB (RAID0) - varsayılan IOPS ve disk başına 25 MB/sn ek aktarım hızı veya eşdeğer Premium SSD v2 |
Önbellek = Premium depolama v1 için Salt Okunur |
# ve günlük disklerinin türü | Premium depolama v1: 1 x P20 Premium depolama v2: 1 x 200 GiB - varsayılan IOPS ve aktarım hızı veya eşdeğer Premium SSD v2 |
Önbellek = YOK |
SQL Server en fazla bellek parametresi | Fiziksel RAM'in %90'ını | Tek örnek varsayma |
Veritabanı boyutu 750 GB ile 2.000 GB arasında olan orta ölçekli bir SQL Server örneği için bir yapılandırma örneği, örneğin orta SAP Business Suite sistemi gibi görünebilir
Yapılandırma | Veritabanı VM'si | Açıklamalar |
---|---|---|
VM Türü | E64s_v3/v4/v5 (64 vCPU/432 GiB RAM) | |
Hızlandırılmış Ağ | Etkinleştir | |
SQL Server sürümü | SQL Server 2019 veya daha yeni | |
# of data devices | 16 | |
# of log devices | 1 | |
# of temp data files | SQL Server 2016'dan bu yana 8 veya varsayılan | |
İşletim sistemi | Windows Server 2019 veya daha yeni | |
Disk toplama | İsterseniz Depolama Alanları | |
Dosya sistemi | NTFS | |
Blok boyutunu biçimlendir | 64 KB | |
# ve veri disklerinin türü | Premium depolama v1: 4 x P30 (RAID0) Premium depolama v2: 4 x 250 GiB - 500 GiB - artı disk başına 2.000 IOPS ve 75 MB/sn aktarım hızı veya eşdeğer Premium SSD v2 |
Önbellek = Premium depolama v1 için Salt Okunur |
# ve günlük disklerinin türü | Premium depolama v1: 1 x P20 Premium depolama v2: 1 x 400 GiB - varsayılan IOPS ve 75 MB/sn ek aktarım hızı veya eşdeğer Premium SSD v2 |
Önbellek = YOK |
SQL Server en fazla bellek parametresi | Fiziksel RAM'in %90'ını | Tek örnek varsayma |
Daha büyük bir SAP Business Suite sistemi gibi veritabanı boyutu 2.000 GB ile 4.000 GB arasında olan daha büyü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ü | E96(d)s_v5 (96 vCPU/672 GiB RAM) | |
Hızlandırılmış Ağ | Etkinleştir | |
SQL Server sürümü | SQL Server 2019 veya daha yeni | |
# of data devices | 24 | |
# of log devices | 1 | |
# of temp data files | SQL Server 2016'dan bu yana 8 veya varsayılan | |
İşletim sistemi | Windows Server 2019 veya daha yeni | |
Disk toplama | İsterseniz Depolama Alanları | |
Dosya sistemi | NTFS | |
Blok boyutunu biçimlendir | 64 KB | |
# ve veri disklerinin türü | Premium depolama v1: 4 x P30 (RAID0) Premium depolama v2: 4 x 500 GiB - 800 GiB - artı disk başına 2500 IOPS ve 100 MB/sn aktarım hızı veya eşdeğer Premium SSD v2 |
Önbellek = Premium depolama v1 için Salt Okunur |
# ve günlük disklerinin türü | Premium depolama v1: 1 x P20 Premium depolama v2: 1 x 400 GiB - artı 1.000 IOPS ve 75 MB/sn ek aktarım hızı veya eşdeğer Premium SSD v2 |
Önbellek = YOK |
SQL Server en fazla bellek parametresi | Fiziksel RAM'in %90'ını | Tek örnek varsayma |
Genel olarak kullanılan büyük bir SAP Business Suite sistemi gibi veritabanı boyutu 4 TB+ olan büyü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ü | M Serisi (1,0 - 4,0 TB RAM) | |
Hızlandırılmış Ağ | Etkinleştir | |
SQL Server sürümü | SQL Server 2019 veya daha yeni | |
# of data devices | 32 | |
# of log devices | 1 | |
# of temp data files | SQL Server 2016'dan bu yana 8 veya varsayılan | |
İşletim sistemi | Windows Server 2019 veya daha yeni | |
Disk toplama | İsterseniz Depolama Alanları | |
Dosya sistemi | NTFS | |
Blok boyutunu biçimlendir | 64 KB | |
# ve veri disklerinin türü | Premium depolama v1: 4+ x P40 (RAID0) Premium depolama v2: 4+ x 1.000 GiB - 4.000 GiB - artı disk başına 4.500 IOPS ve 125 MB/sn aktarım hızı veya eşdeğer Premium SSD v2 |
Önbellek = Premium depolama v1 için Salt Okunur |
# ve günlük disklerinin türü | Premium depolama v1: 1 x P30 Premium depolama v2: 1 x 500 GiB - artı 2.000 IOPS ve 125 MB/sn aktarım hızı veya eşdeğer Premium SSD v2 |
Önbellek = YOK |
SQL Server en fazla bellek parametresi | Fiziksel RAM'in %95'i | 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 küresel SAP Business Suite örneğinin 30 TB veritabanını barındırır. Sistem, Kuzey Amerika n bordro dahil olmak üzere farklı alanlarda tüm finansal işleme, satış ve dağıtım işlemlerini ve daha birçok iş işlemini çalıştırı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 başka bir Azure bölgesinde başka bir zaman uyumsuz çoğaltma. 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ğ | Etkin | |
SQL Server sürümü | SQL Server 2019 | |
# of data files | 32 | |
# of log files | 1 | |
# of temp data files | 8 | |
İşletim sistemi | Windows Server 2019 | |
Disk toplama | 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 = Salt Okunur |
# 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 tempdb disklerinin türü | Premium depolama v1: 1 x P30 veya eşdeğer Premium SSD v2 | Önbelleğe alma yok |
SQL Server en fazla 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. Ancak 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 Sap sistem ortamınızı Azure'da 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 şerit oluşturma.
- Çok fazla diskiniz yok, ancak gerekli IOPS'nize ulaşabildiğinizden emin olmak için yeterli diske sahip olun.
- 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 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.
Sonraki adımlar
Makaleyi okuyun