Aracılığıyla paylaş

Tek bir Azure bölgesinde SAP HANA kullanılabilirliği

  • Makale

Bu makalede, bir Azure bölgesinde SAP HANA için çeşitli kullanılabilirlik senaryoları açıklanmaktadır. Azure'ın dünyanın her yerine yayılmış birçok bölgesi vardır. Azure bölgelerinin listesi için bkz . Azure bölgeleri. Sap HANA'yı tek bir Azure bölgesindeki VM'lere dağıtmak için Microsoft, HANA örneğine sahip tek bir VM'nin dağıtımını sunar. Daha fazla kullanılabilirlik için, FD=1 ile esnek bir ölçek kümesi , kullanılabilirlik alanları veya kullanılabilirlik için HANA sistem çoğaltması kullanan bir kullanılabilirlik kümesi kullanarak iki HANA örneğine sahip iki VM dağıtabilirsiniz.

Kullanılabilirlik Alanları sağlayan Azure bölgeleri, her biri kendi güç kaynağına, soğutmasına ve ağ altyapısına sahip birden çok veri merkezinden oluşur. Tek bir Azure bölgesinde farklı bölgeler sunmanın amacı, iki veya üç kullanılabilir Kullanılabilirlik Alanları arasında uygulamaların dağıtılabilmesini sağlamaktır. Uygulama dağıtımınızı bölgeler arasında dağıtarak, belirli bir Azure Kullanılabilirlik Alanı altyapısını etkileyen güç veya ağ sorunları, uygulamanızın Azure bölgesindeki işlevselliğini tam olarak kesintiye uğratmaz. Bir bölgedeki VM'lerin olası kaybı gibi bazı azaltılmış kapasiteler olsa da, kalan bölgelerdeki VM'ler kesinti olmadan çalışmaya devam eder. Farklı bölgelere yayılan ayrı VM'lerde iki HANA örneği ayarlamak için, FD=1 ile esnek ölçek kümesini veya kullanılabilirlik alanları dağıtım seçeneğini kullanarak VM'leri dağıtma seçeneğiniz vardır.

Bir bölgede daha fazla kullanılabilirlik için, kullanılabilirlik kümesi kullanarak iki HANA örneğine sahip iki VM dağıtmanız tavsiye edilir. Azure Kullanılabilirlik Kümesi, Kullanılabilirlik Kümesi içinde yapılandırılan VM kaynaklarının bir Azure veri merkezi içinde dağıtıldığında birbirlerinden hata yalıtılmasını sağlayan mantıksal bir gruplandırma özelliğidir. Azure, bir Kullanılabilirlik Kümesi içine yerleştirdiğiniz sanal makinelerin birden fazla fiziksel sunucuda, bilgi işlem rafında, depolama biriminde ve ağ anahtarında çalışmasını sağlar. Bazı Azure belgelerinde, bu yapılandırma farklı güncelleştirme ve hata etki alanlarındaki yerleştirmeler olarak adlandırılır. Bu yerleşimler genellikle bir Azure veri merkezinde yer alır. Güç kaynağı ve ağ sorunlarının dağıttığınız veri merkezini etkileyeceğini varsayarsak, tek bir Azure bölgesindeki tüm kapasiteniz etkilenir.

Azure Kullanılabilirlik Alanları temsil eden veri merkezlerinin yerleşimi, farklı bölgelere dağıtılan hizmetler arasında kabul edilebilir ağ gecikme süresi ve veri merkezleri arasındaki mesafe arasında bir risk oluşturur. Doğal felaketler ideal olarak bu bölgedeki tüm Kullanılabilirlik Alanları için güç, ağ kaynağı ve altyapıyı etkilemez. Ancak, anıtsal doğal felaketlerin gösterdiği gibi, Kullanılabilirlik Alanları her zaman tek bir bölgede istediğiniz kullanılabilirliği sağlamayabilir. 20 Eylül 2017'de Porto Riko adasını vuran Maria Kasırgası'nı düşünün. Kasırga temelde 90 mil genişliğindeki adada yaklaşık %100 kesintiye neden oldu.

Tek VM senaryosu

Tek VM senaryosunda SAP HANA örneği için bir Azure VM oluşturursunuz. İşletim sistemi diskini ve tüm veri disklerinizi barındırmak için Azure Premium Depolama kullanırsınız. Yüzde 99,9'luk Azure çalışma süresi SLA'sı ve diğer Azure bileşenlerinin SLA'ları, müşterileriniz için kullanılabilirlik SLA'larınızı yerine getirmeniz için yeterlidir. Bu senaryoda, DBMS katmanını çalıştıran VM'ler için Azure Kullanılabilirlik Kümesi kullanmanız gerekmez. Bu senaryoda iki farklı özelliğe güvenirsiniz:

  • Azure VM otomatik yeniden başlatma (Azure hizmet düzeltmesi olarak da adlandırılır)
  • SAP HANA otomatik yeniden başlatma

Azure VM otomatik yeniden başlatma veya hizmet düzeltme, Azure'da iki düzeyde çalışan bir işlevdir:

  • Azure sunucu konağı, sunucu ana bilgisayarında barındırılan bir VM'nin durumunu denetler.
  • Azure doku denetleyicisi, sunucu konağı durumunu ve kullanılabilirliğini izler.

Sistem durumu denetimi işlevi, bir Azure sunucu konasında barındırılan her vm'nin durumunu izler. Vm iyi durumda değilse, VM'nin sistem durumunu denetleyen Azure konak aracısı tarafından VM'nin yeniden başlatılması başlatılabilir. Yapı denetleyicisi, konak donanımıyla ilgili sorunları gösterebilecek birçok farklı parametreyi denetleyerek konağın durumunu denetler. Ayrıca ağ üzerinden konağın erişilebilirliğini de denetler. Konakla ilgili sorunların göstergesi aşağıdaki olaylara yol açabilir:

  • Konak kötü bir sistem durumu sinyali veriyorsa, konağın yeniden başlatılması ve konakta çalışan VM'lerin yeniden başlatılması tetiklenmiş olur.
  • Başarılı bir yeniden başlatmadan sonra konak iyi durumda değilse, başlangıçta şu anda iyi durumda olmayan düğümde bulunan VM'lerin iyi durumdaki bir konak sunucusuna yeniden dağıtımı başlatılır. Bu durumda, özgün konak iyi durumda değil olarak işaretlenir. Temizlenene veya değiştirilene kadar daha fazla dağıtım için kullanılmaz.
  • İyi durumda olmayan konağın yeniden başlatma işlemi sırasında sorunları varsa, iyi durumdaki bir konak üzerindeki VM'lerin hemen yeniden başlatılması tetiklenmiş olur.

Azure tarafından sağlanan konak ve VM izleme özelliğiyle, konak sorunlarıyla karşılaşan Azure VM'leri iyi durumdaki bir Azure konağı üzerinde otomatik olarak yeniden başlatılır.

Önemli

Azure hizmet iyileştirmesi, konuk işletim sisteminin çekirdek panik durumunda olduğu Linux VM'lerini yeniden başlatmaz. Yaygın olarak kullanılan Linux sürümlerinin varsayılan ayarları, Linux çekirdeğinin panik durumunda olduğu VM'leri veya sunucuyu otomatik olarak yeniden başlatmıyor. Bunun yerine, analiz etmek üzere bir çekirdek hata ayıklayıcısı ekleyebilmek için işletim sisteminin çekirdek panik durumunda tutulması varsayılandır. Azure, konuk işletim sistemiyle bu durumdaki bir VM'yi otomatik olarak yeniden başlatmayarak bu davranışı kabul eder. Varsayım, bu tür oluşumların son derece nadir olduğudur. VM'nin yeniden başlatılmasını etkinleştirmek için varsayılan davranışın üzerine yazabilirsiniz. Varsayılan davranışı değiştirmek için /etc/sysctl.conf dosyasında 'kernel.panic' parametresini etkinleştirin. Bu parametre için ayarladığınız süre saniye olarak ayarlanır. Önerilen yaygın değerler, bu parametre aracılığıyla yeniden başlatmayı tetiklemeden önce 20-30 saniye beklemektir. Daha fazla bilgi için bkz . sysctl.conf.

Bu senaryoda kullandığınız ikinci özellik, yeniden başlatılan bir VM'de çalışan HANA hizmetinin VM yeniden başlatıldıktan sonra otomatik olarak başlatılmasıdır. ÇEŞITLI HANA hizmetlerinin izleme hizmetleri aracılığıyla HANA hizmetini otomatik yeniden başlatmayı ayarlayabilirsiniz.

SAP HANA yapılandırmasına soğuk yük devretme düğümü ekleyerek bu tek VM senaryosunu geliştirebilirsiniz. SAP HANA belgelerinde bu kuruluma konak otomatik kurtarma adı verilir. Bu yapılandırma, sunucu donanımının sınırlı olduğu ve tek sunuculu bir düğümü bir dizi üretim konağı için konak otomatik kurtarma düğümü olarak ayırdığınız şirket içi dağıtım durumunda anlamlı olabilir. Ancak Azure'ın temel alınan altyapısının başarılı bir VM yeniden başlatması için iyi durumda bir hedef sunucu sağladığı Azure'da SAP HANA ana bilgisayarı otomatik kurtarmanın dağıtılması mantıklı değildir. Azure hizmet iyileştirmesi nedeniyle, HANA ana bilgisayar otomatik kurtarma için hazır bekleyen bir düğüm öngören bir başvuru mimarisi yoktur.

Azure'da SAP HANA ölçeği genişletme yapılandırmalarının özel durumu

Bekleme düğümüne veya HANA Sistem Çoğaltma'ya dayalı yüksek kullanılabilirlik mimarileri aşağıdaki belgelerde bulunabilir. HAZıR bekleyen düğümlerin veya HANA sistem çoğaltması yüksek kullanılabilirliğinin SAP HANA ölçeği genişletme yapılandırmalarında kullanılmadığı durumlarda, VM yeniden çalıştırıldıktan sonra Azure VM'lerinin hizmet iyileştirme özelliklerine ve SAP HANA örneğinin otomatik yeniden başlatılmasına bağımlı olabilirsiniz.

İki farklı VM için kullanılabilirlik senaryoları

HANA sisteminin belirli bir bölge içinde kullanılabilirliğini sağlamak için, bölgenin kullanılabilirlik alanları arasında veya bölge içinde iki VM yapılandırma seçeneğiniz vardır. Bu hedefe ulaşmak için vm'leri esnek ölçek kümesi, kullanılabilirlik alanları veya kullanılabilirlik kümesi dağıtım seçeneğini kullanarak yapılandırabilirsiniz. Azure'daki temel kurulum şöyle görünür:

Tüm katmanlara sahip iki VM'nin diyagramı.

Farklı SAP HANA kullanılabilirlik senaryolarını göstermek için diyagramdaki katmanlardan birkaçı atlanır. Diyagram yalnızca VM'leri, konakları, Kullanılabilirlik Kümelerini ve Azure bölgelerini gösteren katmanları gösterir. Azure Sanal Ağ örnekleri, kaynak grupları ve abonelikler bu bölümde açıklanan senaryolarda rol oynamaz.

Yedekleri ikinci bir sanal makineye çoğaltma

En temel kurulumlardan biri yedeklemeleri kullanmaktır. Özellikle, bir VM'den başka bir Azure VM'ye gönderilen işlem günlüğü yedeklemeleriniz olabilir. Azure Depolama türünü seçebilirsiniz. Bu kurulumda, ilk VM'de ikinci VM'ye yürütülen zamanlanmış yedeklemelerin kopyasını betik olarak kullanmak sizin sorumluluğundadır. İkinci VM örneklerini kullanmanız gerekiyorsa tam, artımlı/farklı ve işlem günlüğü yedeklerini ihtiyacınız olan noktaya geri yüklemeniz gerekir.

Mimari şöyle görünür:

Depolama çoğaltmalı iki VM'nin mimarisini gösteren diyagram.

Bu kurulum, harika Kurtarma Noktası Hedefi (RPO) ve Kurtarma Süresi Hedefi (RTO) sürelerine ulaşmak için uygun değildir. Kopyalanan yedeklemeleri kullanarak veritabanının tamamının tamamen geri yüklenmesi gerektiğinden RTO süreleri özellikle zarar görür. Ancak bu kurulum, ana örneklerde istenmeyen veri silme işleminden kurtarmak için kullanışlıdır. Bu kurulumla istediğiniz zaman belirli bir noktaya geri yükleyebilir, verileri ayıklayabilir ve silinen verileri ana örneğinize aktarabilirsiniz. Bu nedenle, yedekleme kopyalama yöntemini diğer yüksek kullanılabilirlik işlevleriyle birlikte kullanmak mantıklı olabilir.

Yedeklemeler kopyalanırken, SAP HANA örneğinin üzerinde çalıştığı ana VM'den daha küçük bir VM kullanabilirsiniz. Daha küçük VM'lere daha az sayıda VHD ekleyebileceğinizi unutmayın. Tek tek VM türlerinin sınırları hakkında bilgi için bkz . Azure'da Linux sanal makineleri için boyutlar.

Otomatik yük devretme olmadan SAP HANA sistem çoğaltması

Bu bölümde açıklanan senaryolarda SAP HANA sistem çoğaltması kullanılır. SAP belgeleri için bkz . Sistem çoğaltma. Otomatik yük devretmesi olmayan senaryolar, tek bir Azure bölgesindeki yapılandırmalar için yaygın değildir. Otomatik yük devretmesi olmayan bir yapılandırma, Pacemaker kurulumundan kaçınmanıza rağmen, el ile izlemeniz ve yük devretmeniz zorunludur. Bu da gerektiğinden ve çabaladığından, müşterilerin çoğu bunun yerine Azure hizmet iyileştirmesini kullanıyor. Bu yapılandırmanın hata senaryoları açısından yardımcı olabileceği bazı uç durumlar vardır. Alternatif olarak, bazı durumlarda müşteri daha fazla verimlilik gerçekleştirmek isteyebilir.

Otomatik yük devretme olmadan ve veri önceden yüklenmeden SAP HANA sistem çoğaltması

Bu senaryoda, 0 RPO elde etmek üzere verileri zaman uyumlu bir şekilde taşımak için SAP HANA sistem çoğaltmasını kullanırsınız. Öte yandan, HANA örnek önbelleğine yük devretme veya verilerin önceden yüklenmesi gerekmeyecek kadar uzun bir RTO'nuz vardır. Bu durumda, aşağıdaki eylemleri gerçekleştirerek yapılandırmanızda daha fazla ekonomi elde edebilirsiniz:

  • İkinci VM'de başka bir SAP HANA örneği çalıştırın. İkinci VM'deki SAP HANA örneği, sanal makinenin belleğinin çoğunu alır. İkinci VM'ye yük devretme durumunda, çoğaltılan verilerin ikinci VM'deki hedeflenen HANA örneğinin önbelleğine yüklenebilmesi için verilerin ikinci VM'de tamamen yüklü olduğu çalışan SAP HANA örneğini kapatmanız gerekir.
  • İkinci VM'de daha küçük bir VM boyutu kullanın. Yük devretme gerçekleşirse, el ile yük devretmeden önce ek bir adımınız vardır. Bu adımda VM'yi kaynak VM'nin boyutuna göre yeniden boyutlandıracaksınız.

Senaryo şöyle görünür:

Depolama çoğaltması olan iki VM'nin diyagramı.

Not

HANA sistem çoğaltma hedefinde veri yüklemesini kullanmasanız bile en az 64 GB belleğe ihtiyacınız vardır. Satır deposu verilerini hedef örneğin belleğinde tutmak için 64 GB'a ek olarak yeterli belleğe de ihtiyacınız vardır.

Otomatik yük devretme olmadan ve veri önceden yükleme ile SAP HANA sistem çoğaltması

Bu senaryoda, ikinci VM'deki HANA örneğine çoğaltılan veriler önceden yüklenir. Bu, verileri önceden yüklememenin iki avantajını ortadan kaldırır. Bu durumda, ikinci VM'de başka bir SAP HANA sistemi çalıştıramazsınız. Daha küçük bir VM boyutu da kullanamazsınız. Bu nedenle müşteriler bu senaryoya nadiren uygulanır.

Otomatik yük devretme ile SAP HANA sistem çoğaltması

Bir Azure bölgesindeki standart ve en yaygın kullanılabilirlik yapılandırmasında, HA paketlerine sahip Linux çalıştıran iki Azure VM'sinin bir yük devretme kümesi tanımlanmıştır. HA Linux kümesi, örnek olarak SLES veya RHEL ile fencing device SLES veya RHEL kullanan çerçeveyi temel alırPacemaker.

SAP HANA perspektifinden bakıldığında, kullanılan çoğaltma modu eşitlenir ve otomatik yük devretme yapılandırılır. İkinci VM'de SAP HANA örneği etkin bekleme düğümü işlevi görür. Bekleme düğümü, birincil SAP HANA örneğinden zaman uyumlu bir değişiklik kaydı akışı alır. HANA birincil düğümünde uygulama tarafından işlemler işlendiği için birincil HANA düğümü, ikincil SAP HANA düğümü işleme kaydını aldığını onaylayana kadar işlemeyi onaylamak için bekler. SAP HANA iki zaman uyumlu çoğaltma modu sunar. Bu iki zaman uyumlu çoğaltma modu arasındaki farkların ayrıntıları ve açıklaması için SAP HANA sistem çoğaltması için SAP çoğaltma modları makalesine bakın.

Genel yapılandırma şöyle görünür:

Depolama çoğaltma ve yük devretme ile iki VM'nin diyagramı.

RPO=0 ve düşük RTO elde etme olanağı sağladığından bu çözümü seçebilirsiniz. SAP HANA istemcilerinin HANA sistem çoğaltma yapılandırmasına bağlanmak için sanal IP adresini kullanması için SAP HANA istemci bağlantısını yapılandırın. Böyle bir yapılandırma, ikincil düğüme yük devretme gerçekleşirse uygulamayı yeniden yapılandırma gereksinimini ortadan kaldırır. Bu senaryoda, birincil ve ikincil VM'ler için Azure VM SKU'ları aynı olmalıdır.

Sonraki adımlar

Azure'da bu yapılandırmaları ayarlama konusunda adım adım yönergeler için bkz:

Azure bölgeleri genelinde SAP HANA kullanılabilirliği hakkında daha fazla bilgi için bkz: