Pacemaker ile SUSE Linux Enterprise Server üzerinde Azure VM'lerinde IBM Db2 LUW'un yüksek kullanılabilirliği
Yüksek kullanılabilirlik ve olağanüstü durum kurtarma (HADR) yapılandırmasında Linux, UNIX ve Windows (LUW) için IBM Db2, birincil veritabanı örneğini çalıştıran bir düğümden ve ikincil veritabanı örneğini çalıştıran en az bir düğümden oluşur. Birincil veritabanı örneğindeki değişiklikler, yapılandırmanıza bağlı olarak zaman uyumlu veya zaman uyumsuz olarak ikincil bir veritabanı örneğine çoğaltılır.
Not
Bu makale, Microsoft'un artık kullanmadığını ifade eden başvurular içerir. Bu terimler yazılımdan kaldırıldığında, bunları bu makaleden kaldıracağız.
Bu makalede Azure sanal makinelerini (VM) dağıtma ve yapılandırma, küme çerçevesini yükleme ve HADR yapılandırmasıyla IBM Db2 LUW yükleme işlemleri açıklanmaktadır.
Makale, HADR veya SAP yazılım yüklemesi ile IBM Db2 LUW yükleme ve yapılandırma konularını kapsamaz. Bu görevleri gerçekleştirmenize yardımcı olmak için SAP ve IBM yükleme kılavuzlarına başvurular sunuyoruz. Bu makale, Azure ortamına özgü bölümlere odaklanır.
DESTEKLENEN IBM Db2 sürümleri, SAP not 1928533 belgelendiği gibi 10.5 ve üzeri sürümlerdir.
Yüklemeye başlamadan önce aşağıdaki SAP notlarına ve belgelerine bakın:
SAP notu | Açıklama |
---|---|
1928533 | Azure'da SAP uygulamaları: Desteklenen ürünler ve Azure VM türleri |
2015553 | Azure'da SAP: Destek önkoşulları |
2178632 | Azure'da SAP için önemli izleme ölçümleri |
2191498 | Azure ile Linux üzerinde SAP: Gelişmiş izleme |
2243692 | Azure üzerinde Linux (IaaS) VM: SAP lisans sorunları |
1984787 | SUSE LINUX Enterprise Server 12: Yükleme notları |
1999351 | SAP için gelişmiş Azure izleme sorunlarını giderme |
2233094 | DB6: Azure'da Linux, UNIX ve Windows için IBM Db2 kullanan SAP uygulamaları - ek bilgiler |
1612105 | DB6: HADR ile Db2 hakkında SSS |
Belgeler |
---|
SAP Community Wiki: Linux için tüm gerekli SAP Notlarına sahiptir |
Linux üzerinde SAP için Azure Sanal Makineler planlama ve uygulama kılavuzu |
Linux üzerinde SAP için Azure Sanal Makineler dağıtımı (bu makale) |
Linux üzerinde SAP için Azure Sanal Makineler veritabanı yönetim sistemi (DBMS) dağıtımı kılavuzu |
Azure'da SAP iş yükü planlama ve dağıtım denetim listesi |
SAP Uygulamaları için SUSE Linux Enterprise Server 12 SP4 en iyi yöntemler kılavuzları |
SUSE Linux Enterprise Yüksek Kullanılabilirlik Uzantısı 12 SP4 |
SAP iş yükü için IBM Db2 Azure Sanal Makineler DBMS dağıtımı |
IBM Db2 HADR 11.1 |
IBM Db2 HADR R 10.5 |
Genel bakış
Yüksek kullanılabilirlik elde etmek için HADR ile IBM Db2 LUW, kullanılabilirlik alanları arasında veya kullanılabilirlik kümesinde esnek düzenleme ile bir sanal makine ölçek kümesinde dağıtılan en az iki Azure sanal makinesine yüklenir.
Aşağıdaki grafiklerde iki veritabanı sunucusu Azure VM'sinin kurulumu gösterilir. Her iki veritabanı sunucusu Azure VM'lerinin de kendi depolama alanı vardır ve çalışır durumdadır. HADR'de, Azure VM'lerinden birinde yer alan bir veritabanı örneği birincil örneğin rolüne sahiptir. Tüm istemciler bu birincil örneğe bağlıdır. Veritabanı işlemlerindeki tüm değişiklikler Db2 işlem günlüğünde yerel olarak kalıcı hale uygulanır. İşlem günlüğü kayıtları yerel olarak kalıcı hale gelince, kayıtlar TCP/IP aracılığıyla ikinci veritabanı sunucusundaki veritabanı örneğine, hazır bekleyen sunucuya veya bekleme örneğine aktarılır. Bekleyen örnek, aktarılan işlem günlüğü kayıtlarını ileterek yerel veritabanını güncelleştirir. Bu şekilde, hazır bekleyen sunucu birincil sunucuyla eşitlenmiş olarak tutulur.
HADR yalnızca bir çoğaltma işlevidir. Hata algılaması ve otomatik devralma veya yük devretme olanakları yoktur. Devralma veya bekleme sunucusuna aktarım, veritabanı yöneticisi tarafından el ile başlatılmalıdır. Otomatik devralma ve hata algılama gerçekleştirmek için Linux Pacemaker kümeleme özelliğini kullanabilirsiniz. Pacemaker iki veritabanı sunucusu örneğini izler. Birincil veritabanı sunucusu örneği kilitlendiğinde Pacemaker, hazır bekleyen sunucu tarafından otomatik hadr devralma işlemi başlatır. Pacemaker ayrıca sanal IP adresinin yeni birincil sunucuya atanmasını sağlar.
SAP uygulama sunucularının birincil veritabanına bağlanması için bir sanal ana bilgisayar adı ve bir sanal IP adresi gerekir. Yük devretme sonrasında SAP uygulama sunucuları yeni birincil veritabanı örneğine bağlanır. Azure ortamında, SANAL IP adresini IBM Db2 HADR için gereken şekilde kullanmak için bir Azure yük dengeleyici gerekir.
HADR ve Pacemaker ile IBM Db2 LUW'un yüksek oranda kullanılabilir bir SAP sistemi kurulumuna nasıl uyum sağladığını tam olarak anlamanıza yardımcı olmak için aşağıdaki görüntüde, IBM Db2 veritabanını temel alan bir SAP sisteminin yüksek oranda kullanılabilir kurulumuna genel bir bakış sunulmaktadır. Bu makale yalnızca IBM Db2'yi kapsar, ancak sap sisteminin diğer bileşenlerini ayarlama hakkında diğer makalelere başvurular sağlar.
Gerekli adımlara üst düzey genel bakış
IBM Db2 yapılandırmasını dağıtmak için şu adımları izlemeniz gerekir:
- Ortamınızı planlayın.
- VM'leri dağıtın.
- SUSE Linux'ı güncelleştirin ve dosya sistemlerini yapılandırın.
- Pacemaker'ı yükleyin ve yapılandırın.
- Yüksek oranda kullanılabilir NFS yükleyin.
- ASCS/ERS'i ayrı bir kümeye yükleyin.
- Dağıtılmış/Yüksek Kullanılabilirlik seçeneği (SWPM) ile IBM Db2 veritabanını yükleyin.
- İkincil bir veritabanı düğümü ve örneği yükleyip oluşturun ve HADR'yi yapılandırın.
- HADR'nin çalıştığını onaylayın.
- IBM Db2'yi denetlemek için Pacemaker yapılandırmasını uygulayın.
- Azure Load Balancer'ı yapılandırın.
- Birincil ve iletişim kutusu uygulama sunucularını yükleyin.
- SAP uygulama sunucularının yapılandırmasını denetleyin ve uyarlar.
- Yük devretme ve devralma testleri gerçekleştirin.
HADR ile IBM Db2 LUW barındırmak için Azure altyapısını planlama
Dağıtımı yürütmeden önce planlama işlemini tamamlayın. Planlama, Azure'da HADR ile Db2 yapılandırması dağıtmanın temelini oluşturur. IMB Db2 LUW (SAP ortamının veritabanı bölümü) planlamasının parçası olması gereken temel öğeler aşağıdaki tabloda listelenmiştir:
Konu | Kısa açıklama |
---|---|
Azure kaynak gruplarını tanımlama | VM, sanal ağ, Azure Load Balancer ve diğer kaynakları dağıttığınız kaynak grupları. Mevcut veya yeni olabilir. |
Sanal ağ / Alt ağ tanımı | IBM Db2 ve Azure Load Balancer vm'lerinin dağıtıldığı yer. Mevcut veya yeni oluşturulmuş olabilir. |
IBM Db2 LUW barındıran sanal makineler | VM boyutu, depolama, ağ, IP adresi. |
IBM Db2 veritabanı için sanal ana bilgisayar adı ve sanal IP | SAP uygulama sunucularının bağlantısı için kullanılan sanal IP veya ana bilgisayar adı. db-virt-hostname, db-virt-ip. |
Azure eskrim | Azure eskrim veya SBD eskrim (kesinlikle önerilir). Bölünmüş beyin durumlarından kaçınma yöntemi. |
SBD VM | SBD sanal makine boyutu, depolama, ağ. |
Azure Load Balancer | Standart kullanımı (önerilen), Db2 veritabanı için yoklama bağlantı noktası (önerimiz 62500) yoklama bağlantı noktası. |
Ad çözümlemesi | Ad çözümlemenin ortamda nasıl çalıştığı. DNS hizmeti kesinlikle önerilir. Yerel konaklar dosyası kullanılabilir. |
Azure'da Linux Pacemaker hakkında daha fazla bilgi için bkz . Azure'da SUSE Linux Enterprise Server üzerinde Pacemaker'ı ayarlama.
Önemli
Db2 sürüm 11.5.6 ve üzeri sürümler için IBM'den Pacemaker kullanan Tümleşik çözümü kesinlikle öneririz.
- Pacemaker kullanarak tümleşik çözüm.
- Microsoft Azure'da kullanılabilen alternatif veya ek yapılandırmalar.
SUSE Linux'ta dağıtım
IBM Db2 LUW kaynak aracısı SAP Uygulamaları için SUSE Linux Enterprise Server'a dahildir. Bu belgede açıklanan kurulum için SAP Uygulamaları için SUSE Linux Server kullanmanız gerekir. Azure Market, SAP Applications 12 için SUSE Enterprise Server'a yönelik, yeni Azure sanal makinelerini dağıtmak için kullanabileceğiniz bir görüntü içerir. Azure VM Market'te bir VM görüntüsü seçtiğinizde Azure Market aracılığıyla SUSE tarafından sunulan çeşitli destek veya hizmet modellerine dikkat edin.
Konaklar: DNS güncelleştirmeleri
Sanal konak adları da dahil olmak üzere tüm konak adlarının listesini yapın ve DNS sunucularınızı, konak adı çözümlemesine uygun IP adresini etkinleştirmek üzere güncelleştirin. DNS sunucusu yoksa veya DNS girdilerini güncelleştiremiyor ve oluşturamıyorsanız, bu senaryoya katılan tek tek VM'lerin yerel konak dosyalarını kullanmanız gerekir. Konak dosyaları girdileri kullanıyorsanız, girdilerin SAP sistem ortamındaki tüm VM'lere uygulandığından emin olun. Ancak, ideal olarak Azure'a genişleten DNS'nizi kullanmanızı öneririz
El ile dağıtım
Seçili işletim sisteminin IBM Db2 LUW için IBM/SAP tarafından desteklendiğinden emin olun. Azure VM'leri ve Db2 sürümleri için desteklenen işletim sistemi sürümlerinin listesi SAP not 1928533... Tek tek Db2 sürümüne göre işletim sistemi sürümlerinin listesi SAP Ürün Kullanılabilirlik Matrisi'nde bulunur. Bu veya sonraki SUSE Linux sürümlerinde Azure ile ilgili performans geliştirmeleri nedeniyle en az SLES 12 SP4 kullanmanızı kesinlikle öneririz.
- Bir kaynak grubu oluşturun veya seçin.
- Bir sanal ağ ve alt ağ oluşturun veya seçin.
- SAP sanal makineleri için uygun bir dağıtım türü seçin. Genellikle esnek düzenlemeye sahip bir sanal makine ölçek kümesidir.
- Sanal Makine 1'i oluşturun.
- Azure Market SAP görüntüsü için SLES kullanın.
- 3. adımda oluşturulan ölçek kümesini, kullanılabilirlik bölgesini veya kullanılabilirlik kümesini seçin.
- Sanal Makine 2 oluşturun.
- Azure Market SAP görüntüsü için SLES kullanın.
- 3. adımda oluşturulan ölçek kümesini, kullanılabilirlik bölgesini veya kullanılabilirlik kümesini seçin (4. adımda olduğu gibi değil).
- VM'lere veri diskleri ekleyin ve ardından IBM Db2 Azure Sanal Makineler SAP iş yükü için DBMS dağıtımı makalesindeki dosya sistemi kurulumu önerisini gözden geçirin.
IBM Db2 LUW ve SAP ortamını yükleme
IBM Db2 LUW tabanlı bir SAP ortamını yüklemeye başlamadan önce aşağıdaki belgeleri gözden geçirin:
- Azure belgeleri
- SAP belgeleri
- IBM belgeleri
Bu belgelerin bağlantıları bu makalenin giriş bölümünde verilmiştir.
NETWeaver tabanlı uygulamaları IBM Db2 LUW'a yükleme hakkında SAP yükleme kılavuzlarını gözden geçirin.
SAP Yükleme Kılavuzu Bulucu'nu kullanarak kılavuzları SAP Yardım portalında bulabilirsiniz.
Aşağıdaki filtreleri ayarlayarak portalda görüntülenen kılavuz sayısını azaltabilirsiniz:
- "Yeni bir sistem yükle"
- Veritabanım: "Linux, Unix ve Windows için IBM Db2"
- SAP NetWeaver sürümleri, yığın yapılandırması veya işletim sistemi için ek filtreler
HADR ile IBM Db2 LUW kurulumu için yükleme ipuçları
Birincil IBM Db2 LUW veritabanı örneğini ayarlamak için:
- Yüksek kullanılabilirlik veya dağıtılmış seçeneğini kullanın.
- SAP ASCS/ERS ve Veritabanı örneğini yükleyin.
- Yeni yüklenen veritabanının yedeğini alın.
Önemli
Yükleme sırasında ayarlanan "Veritabanı İletişimi bağlantı noktasını" not edin. Her iki veritabanı örneği için de aynı bağlantı noktası numarası olmalıdır
SAP homojen sistem kopyalama yordamını kullanarak Bekleme veritabanı sunucusunu ayarlamak için şu adımları yürütebilirsiniz:
Sistem kopyalama seçeneğini Hedef sistemler>Dağıtılmış>Veritabanı örneği'ni >seçin.
Kopyalama yöntemi olarak, hazır bekleyen sunucu örneğinde yedeklemeyi geri yüklemek için yedeklemeyi kullanabilmek için Homojen Sistem'i seçin.
Veritabanını homojen sistem kopyası için geri yüklemek için çıkış adımına ulaştığınızda yükleyiciden çıkın. Veritabanını birincil konağın yedeğinden geri yükleyin. Sonraki tüm yükleme aşamaları birincil veritabanı sunucusunda zaten yürütüldü.
IBM Db2 için HADR'i ayarlayın.
Not
Azure ve Pacemaker'a özgü yükleme ve yapılandırma için: SAP Yazılım Sağlama Yöneticisi aracılığıyla yükleme yordamı sırasında IBM Db2 LUW için yüksek kullanılabilirlik hakkında açık bir soru vardır:
- IBM Db2 pureScale'i seçmeyin.
- Çok Platformlu Formlar için IBM Tivoli Sistem Otomasyonu Yükle'yi seçmeyin.
- Küme yapılandırma dosyaları oluştur'ı seçmeyin.
Linux Pacemaker için bir SBD cihazı kullandığınızda aşağıdaki Db2 HADR parametrelerini ayarlayın:
- HADR eş penceresi süresi (saniye) (HADR_PEER_WINDOW) = 300
- HADR zaman aşımı değeri (HADR_TIMEOUT) = 60
Azure Pacemaker eskrim aracısını kullanırken aşağıdaki parametreleri ayarlayın:
- HADR eş penceresi süresi (saniye) (HADR_PEER_WINDOW) = 900
- HADR zaman aşımı değeri (HADR_TIMEOUT) = 60
İlk yük devretme/devralma testini temel alan önceki parametreleri öneririz. Bu parametre ayarlarıyla yük devretme ve devralma işlevlerinin düzgün olup olmadığını test edin. Tek tek yapılandırmalar farklılık gösterebileceğinden, parametreler ayarlama gerektirebilir.
Önemli
Normal başlangıçlı HADR yapılandırmasına sahip IBM Db2'ye özgü: Birincil veritabanı örneğini başlatabilmeniz için önce ikincil veya bekleyen veritabanı örneğinin çalışır durumda olması gerekir.
Tanıtım amacıyla ve bu makalede açıklanan yordamlar için veritabanı SID'i PTR'dir.
IBM Db2 HADR denetimi
HADR'yi yapılandırdıktan ve birincil ve bekleme düğümlerinde PEER ve CONNECTED durumu olduktan sonra aşağıdaki denetimi gerçekleştirin:
Execute command as db2<sid> db2pd -hadr -db <SID>
#Primary output:
# Database Member 0 -- Database PTR -- Active -- Up 1 days 01:51:38 -- Date 2019-02-06-15.35.28.505451
#
# HADR_ROLE = PRIMARY
# REPLAY_TYPE = PHYSICAL
# HADR_SYNCMODE = NEARSYNC
# STANDBY_ID = 1
# LOG_STREAM_ID = 0
# HADR_STATE = PEER
# HADR_FLAGS = TCP_PROTOCOL
# PRIMARY_MEMBER_HOST = azibmdb02
# PRIMARY_INSTANCE = db2ptr
# PRIMARY_MEMBER = 0
# STANDBY_MEMBER_HOST = azibmdb01
# STANDBY_INSTANCE = db2ptr
# STANDBY_MEMBER = 0
# HADR_CONNECT_STATUS = CONNECTED
# HADR_CONNECT_STATUS_TIME = 02/05/2019 13:51:47.170561 (1549374707)
# HEARTBEAT_INTERVAL(seconds) = 15
# HEARTBEAT_MISSED = 0
# HEARTBEAT_EXPECTED = 6137
# HADR_TIMEOUT(seconds) = 60
# TIME_SINCE_LAST_RECV(seconds) = 13
# PEER_WAIT_LIMIT(seconds) = 0
# LOG_HADR_WAIT_CUR(seconds) = 0.000
# LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000025
# LOG_HADR_WAIT_ACCUMULATED(seconds) = 434.595
# LOG_HADR_WAIT_COUNT = 223713
# SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
# SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 374400
# PRIMARY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
# STANDBY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
# HADR_LOG_GAP(bytes) = 0
# STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
# STANDBY_RECV_REPLAY_GAP(bytes) = 0
# PRIMARY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
# STANDBY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
# STANDBY_REPLAY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
# STANDBY_RECV_BUF_SIZE(pages) = 2048
# STANDBY_RECV_BUF_PERCENT = 0
# STANDBY_SPOOL_LIMIT(pages) = 0
# STANDBY_SPOOL_PERCENT = NULL
# STANDBY_ERROR_TIME = NULL
# PEER_WINDOW(seconds) = 300
# PEER_WINDOW_END = 02/06/2019 15:40:25.000000 (1549467625)
# READS_ON_STANDBY_ENABLED = N
#Secondary output:
# Database Member 0 -- Database PTR -- Standby -- Up 1 days 01:46:43 -- Date 2019-02-06-15.38.25.644168
#
# HADR_ROLE = STANDBY
# REPLAY_TYPE = PHYSICAL
# HADR_SYNCMODE = NEARSYNC
# STANDBY_ID = 0
# LOG_STREAM_ID = 0
# HADR_STATE = PEER
# HADR_FLAGS = TCP_PROTOCOL
# PRIMARY_MEMBER_HOST = azibmdb02
# PRIMARY_INSTANCE = db2ptr
# PRIMARY_MEMBER = 0
# STANDBY_MEMBER_HOST = azibmdb01
# STANDBY_INSTANCE = db2ptr
# STANDBY_MEMBER = 0
# HADR_CONNECT_STATUS = CONNECTED
# HADR_CONNECT_STATUS_TIME = 02/05/2019 13:51:47.205067 (1549374707)
# HEARTBEAT_INTERVAL(seconds) = 15
# HEARTBEAT_MISSED = 0
# HEARTBEAT_EXPECTED = 6186
# HADR_TIMEOUT(seconds) = 60
# TIME_SINCE_LAST_RECV(seconds) = 5
# PEER_WAIT_LIMIT(seconds) = 0
# LOG_HADR_WAIT_CUR(seconds) = 0.000
# LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000023
# LOG_HADR_WAIT_ACCUMULATED(seconds) = 434.595
# LOG_HADR_WAIT_COUNT = 223725
# SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
# SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 372480
# PRIMARY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
# STANDBY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
# HADR_LOG_GAP(bytes) = 0
# STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
# STANDBY_RECV_REPLAY_GAP(bytes) = 155
# PRIMARY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
# STANDBY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
# STANDBY_REPLAY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
# STANDBY_RECV_BUF_SIZE(pages) = 2048
# STANDBY_RECV_BUF_PERCENT = 0
# STANDBY_SPOOL_LIMIT(pages) = 0
# STANDBY_SPOOL_PERCENT = NULL
# STANDBY_ERROR_TIME = NULL
# PEER_WINDOW(seconds) = 300
# PEER_WINDOW_END = 02/06/2019 15:43:19.000000 (1549467799)
# READS_ON_STANDBY_ENABLED = N
Azure Load Balancer'ı yapılandırma
VM yapılandırması sırasında ağ bölümünde yük dengeleyiciden çıkma seçeneğiniz vardır. DB2 veritabanının yüksek kullanılabilirlik kurulumu için standart yük dengeleyiciyi ayarlamak için aşağıdaki adımları izleyin.
Azure portalını kullanarak yüksek kullanılabilirlikli bir SAP sistemi için standart yük dengeleyici ayarlamak için Yük dengeleyici oluşturma makalesindeki adımları izleyin. Yük dengeleyicinin kurulumu sırasında aşağıdaki noktaları göz önünde bulundurun:
- Ön uç IP Yapılandırması: Ön uç IP'si oluşturun. Veritabanı sanal makinelerinizle aynı sanal ağı ve alt ağ adını seçin.
- Arka Uç Havuzu: Arka uç havuzu oluşturun ve veritabanı VM'leri ekleyin.
- Gelen kuralları: Yük dengeleme kuralı oluşturun. Her iki yük dengeleme kuralı için de aynı adımları izleyin.
- Ön uç IP adresi: Ön uç IP'lerini seçin.
- Arka uç havuzu: Bir arka uç havuzu seçin.
- Yüksek kullanılabilirlik bağlantı noktaları: Bu seçeneği belirleyin.
- Protokol: TCP'yi seçin.
- Sistem Durumu Yoklaması: Aşağıdaki ayrıntıları içeren bir sistem durumu yoklaması oluşturun:
- Protokol: TCP'yi seçin.
- Bağlantı noktası: Örneğin, 625<örnek-no.>.
- Aralık: 5 girin.
- Yoklama Eşiği: 2 girin.
- Boşta kalma zaman aşımı (dakika): 30 girin.
- Kayan IP'yi etkinleştir: Bu seçeneği belirleyin.
Not
Portalda iyi durumda olmayan eşik olarak bilinen durum yoklaması yapılandırma özelliğine numberOfProbes
uyulmaz. Başarılı veya başarısız ardışık yoklama sayısını denetlemek için özelliğini probeThreshold
olarak 2
ayarlayın. Şu anda Azure portalını kullanarak bu özelliği ayarlamak mümkün değildir, bu nedenle Azure CLI veya PowerShell komutunu kullanın.
Not
Genel IP adresleri olmayan VM'ler Standart Azure Load Balancer'ın iç (genel IP adresi yok) örneğinin arka uç havuzuna yerleştirildiğinde, genel uç noktalara yönlendirmeye izin verecek daha fazla yapılandırma yapılmadığı sürece giden İnternet bağlantısı olmaz. Giden bağlantı elde etme hakkında daha fazla bilgi için bkz. SAP yüksek kullanılabilirlik senaryolarında Azure Standart Load Balancer kullanan VM'ler için genel uç nokta bağlantısı.
Önemli
Azure Load Balancer'ın arkasına yerleştirilen Azure VM'lerinde TCP zaman damgalarını etkinleştirmeyin. TCP zaman damgalarının etkinleştirilmesi sistem durumu yoklamalarının başarısız olmasına neden olabilir. parametresini net.ipv4.tcp_timestamps
olarak 0
ayarlayın. Daha fazla bilgi için bkz . Load Balancer sistem durumu yoklamaları.
Pacemaker kümesini oluşturma
Bu IBM Db2 sunucusu için temel bir Pacemaker kümesi oluşturmak için bkz . Azure'da SUSE Linux Enterprise Server üzerinde Pacemaker'ı ayarlama.
Db2 Pacemaker yapılandırması
Düğüm hatası durumunda pacemaker'ı otomatik yük devretme için kullandığınızda Db2 örneklerinizi ve Pacemaker'ı buna göre yapılandırmanız gerekir. Bu bölümde bu tür bir yapılandırma açıklanmaktadır.
Aşağıdaki öğelerden biri ön eklenmiştir:
- [A]: Tüm düğümler için geçerlidir
- [1]: Yalnızca düğüm 1 için geçerlidir
- [2]: Yalnızca düğüm 2 için geçerlidir
[A] Pacemaker yapılandırması için önkoşullar:
- db2stop ile db2<sid> kullanıcısıyla her iki veritabanı sunucusunu da kapatın.
- db2<sid> kullanıcısının kabuk ortamını /bin/ksh olarak değiştirin. Yast aracını kullanmanızı öneririz.
Pacemaker yapılandırması
Önemli
Son testlerde netcat'in yalnızca bir bağlantıyı işleme sınırlaması ve kapsam nedeniyle isteklere yanıt vermeyi durdurduğu durumlar ortaya çıktı. Netcat kaynağı Azure Load balancer isteklerini dinlemeyi durdurur ve kayan IP kullanılamaz duruma gelir. Mevcut Pacemaker kümeleri için geçmişte netcat'i socat ile değiştirmenizi öneririz. Şu anda paket kaynak aracılarının parçası olan azure-lb kaynak aracısını aşağıdaki paket sürümü gereksinimleriyle kullanmanızı öneririz:
- SLES 12 SP4/SP5 için, sürüm en az resource-agents-4.3.018.a7fb5035-3.30.1 olmalıdır.
- SLES 15/15 SP1 için, sürüm en az resource-agents-4.3.0184.6ee15eb2-4.13.1 olmalıdır.
Değişikliğin kısa bir kapalı kalma süresi gerektirdiğini unutmayın.
Mevcut Pacemaker kümelerinde yapılandırma, Azure Load-Balancer Algılama Sağlamlaştırma'da açıklandığı gibi socat kullanacak şekilde zaten değiştirildiyse, hemen azure-lb kaynak aracısına geçiş yapmanız gerekmez.
[1] IBM Db2 HADR'ye özgü Pacemaker yapılandırması:
# Put Pacemaker into maintenance mode sudo crm configure property maintenance-mode=true
[1] IBM Db2 kaynakları oluşturma:
# Replace **bold strings** with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer. sudo crm configure primitive rsc_Db2_db2ptr_PTR db2 \ params instance="db2ptr" dblist="PTR" \ op start interval="0" timeout="130" \ op stop interval="0" timeout="120" \ op promote interval="0" timeout="120" \ op demote interval="0" timeout="120" \ op monitor interval="30" timeout="60" \ op monitor interval="31" role="Master" timeout="60" # Configure virtual IP - same as Azure Load Balancer IP sudo crm configure primitive rsc_ip_db2ptr_PTR IPaddr2 \ op monitor interval="10s" timeout="20s" \ params ip="10.100.0.10" # Configure probe port for Azure load Balancer sudo crm configure primitive rsc_nc_db2ptr_PTR azure-lb port=62500 \ op monitor timeout=20s interval=10 sudo crm configure group g_ip_db2ptr_PTR rsc_ip_db2ptr_PTR rsc_nc_db2ptr_PTR sudo crm configure ms msl_Db2_db2ptr_PTR rsc_Db2_db2ptr_PTR \ meta target-role="Started" notify="true" sudo crm configure colocation col_db2_db2ptr_PTR inf: g_ip_db2ptr_PTR:Started msl_Db2_db2ptr_PTR:Master sudo crm configure order ord_db2_ip_db2ptr_PTR inf: msl_Db2_db2ptr_PTR:promote g_ip_db2ptr_PTR:start sudo crm configure rsc_defaults resource-stickiness=1000 sudo crm configure rsc_defaults migration-threshold=5000
[1] IBM Db2 kaynaklarını başlatın:
Pacemaker'ı bakım modundan çıkar.
# Put Pacemaker out of maintenance-mode - that start IBM Db2 sudo crm configure property maintenance-mode=false
[1] Küme durumunun tamam olduğundan ve tüm kaynakların başlatıldığından emin olun. Kaynakların hangi düğümde çalıştığı önemli değildir.
sudo crm status # 2 nodes configured # 5 resources configured # Online: [ azibmdb01 azibmdb02 ] # Full list of resources: # stonith-sbd (stonith:external/sbd): Started azibmdb02 # Resource Group: g_ip_db2ptr_PTR # rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02 # rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02 # Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR] # Masters: [ azibmdb02 ] # Slaves: [ azibmdb01 ]
Önemli
Pacemaker kümelenmiş Db2 örneğini Pacemaker araçlarını kullanarak yönetmeniz gerekir. db2stop gibi db2 komutlarını kullanırsanız Pacemaker eylemi kaynak hatası olarak algılar. Bakım gerçekleştiriyorsanız düğümleri veya kaynakları bakım moduna alabilirsiniz. Pacemaker izleme kaynaklarını askıya alır ve ardından normal db2 yönetim komutlarını kullanabilirsiniz.
Bağlantı için sanal IP kullanmak üzere SAP profillerinde değişiklik yapma
HADR yapılandırmasının birincil örneğine bağlanmak için SAP uygulama katmanının Azure Load Balancer için tanımladığınız ve yapılandırdığınız sanal IP adresini kullanması gerekir. Aşağıdaki değişiklikler gereklidir:
/sapmnt/<SID>/profile/DEFAULT. PFL
SAPDBHOST = db-virt-hostname
j2ee/dbhost = db-virt-hostname
/sapmnt/<SID>/global/db6/db2cli.ini
Hostname=db-virt-hostname
Birincil ve iletişim kutusu uygulama sunucularını yükleme
Db2 HADR yapılandırmasına karşı birincil ve iletişim kutusu uygulama sunucularını yüklerken, yapılandırma için seçtiğiniz sanal ana bilgisayar adını kullanın.
Db2 HADR yapılandırmasını oluşturmadan önce yüklemeyi gerçekleştirdiyseniz, önceki bölümde açıklandığı gibi ve SAP Java yığınları için aşağıdaki değişiklikleri yapın.
ABAP+Java veya Java yığın sistemleri JDBC URL denetimi
JDBC URL'sini denetlemek veya güncelleştirmek için J2EE Yapılandırma aracını kullanın. J2EE Yapılandırma aracı bir grafik aracı olduğundan X sunucusunun yüklü olması gerekir:
J2EE örneğinin birincil uygulama sunucusunda oturum açın ve şu komutu yürütür:
sudo /usr/sap/*SID*/*Instance*/j2ee/configtool/configtool.sh
Sol çerçevede güvenlik deposu'na tıklayın.
Sağ çerçevede jdbc/pool/SAPSID>/<url anahtarını seçin.
JDBC URL'sindeki ana bilgisayar adını sanal konak adıyla değiştirin.
jdbc:db2://db-virt-hostname:5912/TSP:deferPrepares=0
Ekle'yi seçin.
Değişikliklerinizi kaydetmek için sol üst taraftaki disk simgesini seçin.
Yapılandırma aracını kapatın.
Java örneğini yeniden başlatın.
HADR kurulumu için günlük arşivlemeyi yapılandırma
HADR kurulumu için Db2 günlük arşivlemeyi yapılandırmak için hem birincil hem de bekleme veritabanını tüm günlük arşiv konumlarından otomatik günlük alma özelliğine sahip olacak şekilde yapılandırmanızı öneririz. Hem birincil hem de hazır bekleyen veritabanının, veritabanı örneklerinden birinin günlük dosyalarını arşivleyebileceği tüm günlük arşiv konumlarından günlük arşiv dosyalarını alabilmesi gerekir.
Günlük arşivleme yalnızca birincil veritabanı tarafından gerçekleştirilir. Veritabanı sunucularının HADR rollerini değiştirirseniz veya bir hata oluşursa, yeni birincil veritabanı günlük arşivlemeden sorumludur. Birden çok günlük arşiv konumu ayarladıysanız günlükleriniz iki kez arşivlenebilir. Yerel veya uzaktan yakalama durumunda, arşivlenmiş günlükleri eski birincil sunucudan yeni birincil sunucunun etkin günlük konumuna el ile kopyalamanız da gerekebilir.
Günlüklerin her iki düğümden de yazıldığı ortak bir NFS paylaşımı yapılandırmanızı öneririz. NFS paylaşımının yüksek oranda kullanılabilir olması gerekir.
Aktarımlar veya profil dizini için mevcut yüksek oranda kullanılabilir NFS paylaşımlarını kullanabilirsiniz. Daha fazla bilgi için bkz.
- SUSE Linux Enterprise Server'da Azure VM'lerinde NFS için yüksek kullanılabilirlik.
- SAP Uygulamaları için Azure NetApp Files ile SUSE Linux Enterprise Server üzerindeki Azure VM'lerinde SAP NetWeaver için yüksek kullanılabilirlik.
- Azure NetApp Files (NFS paylaşımları oluşturmak için).
Küme kurulumunu test edin
Bu bölümde Db2 HADR kurulumunuzu nasıl test edebilirsiniz açıklanmaktadır. Her test, kullanıcı kökü olarak oturum açtığınızı ve IBM Db2 birincil öğesinin azibmdb01 sanal makinesinde çalıştığını varsayar.
Tüm test çalışmalarının ilk durumu burada açıklanmıştır: (crm_mon -r veya crm durumu)
- crm durumu , Yürütme zamanında Pacemaker durumunun anlık görüntüsüdür.
- crm_mon -r , Pacemaker durumunun sürekli çıkışıdır.
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Stopped
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
rsc_Db2_db2ptr_PTR (ocf::heartbeat:db2): Promoting azibmdb01
Slaves: [ azibmdb02 ]
Sap sistemindeki özgün durum, aşağıdaki görüntüde gösterildiği gibi İşlem DBACOCKPIT > Yapılandırmasına > Genel Bakış bölümünde belgelenmiştir:
IBM Db2'nin devralma testi
Önemli
Teste başlamadan önce şunları yaptığınızdan emin olun:
Pacemaker'ın başarısız eylemleri (crm durumu) yok.
Konum kısıtlaması yoktur (geçiş testinin artıkları).
IBM Db2 HADR eşitlemesi çalışıyor. Kullanıcı db2<sid ile denetleyin>
db2pd -hadr -db <DBSID>
Aşağıdaki komutu yürüterek birincil Db2 veritabanını çalıştıran düğümü geçirin:
crm resource migrate msl_Db2_db2ptr_PTR azibmdb02
Geçiş tamamlandıktan sonra crm durumu çıktısı şöyle görünür:
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb02 ]
Slaves: [ azibmdb01 ]
Sap sistemindeki özgün durum, aşağıdaki görüntüde gösterildiği gibi İşlem DBACOCKPIT > Yapılandırmasına > Genel Bakış bölümünde belgelenmiştir:
"Crm kaynak geçişi" ile kaynak geçişi konum kısıtlamaları oluşturur. Konum kısıtlamaları silinmelidir. Konum kısıtlamaları silinmezse kaynak yeniden çalışmaz veya istenmeyen devralmalarla karşılaşabilirsiniz.
Kaynağı azibmdb01 konumuna geri geçirin ve konum kısıtlamalarını temizleyin
crm resource migrate msl_Db2_db2ptr_PTR azibmdb01
crm resource clear msl_Db2_db2ptr_PTR
- crm kaynak geçişi <res_name><ana bilgisayar>: Konum kısıtlamaları oluşturur ve devralmayla ilgili sorunlara neden olabilir
- crm resource clear <res_name>: Konum kısıtlamalarını temizler
- crm kaynak temizleme <res_name>: Kaynağın tüm hatalarını temizler
SBD eskrim test etme
Bu durumda, SUSE Linux kullanırken yapmanızı önerdiğimiz SBD eskrim test ediyoruz.
azibmdb01:~ # ps -ef|grep sbd
root 2374 1 0 Feb05 ? 00:00:17 sbd: inquisitor
root 2378 2374 0 Feb05 ? 00:00:40 sbd: watcher: /dev/disk/by-id/scsi-36001405fbbaab35ee77412dacb77ae36 - slot: 0 - uuid: 27cad13a-0bce-4115-891f-43b22cfabe65
root 2379 2374 0 Feb05 ? 00:01:51 sbd: watcher: Pacemaker
root 2380 2374 0 Feb05 ? 00:00:18 sbd: watcher: Cluster
azibmdb01:~ # kill -9 2374
Azibmdb01 küme düğümü yeniden başlatılmalıdır. IBM Db2 birincil HADR rolü azibmdb02'ye taşınacak. azibmdb01 yeniden çevrimiçi olduğunda, Db2 örneği ikincil veritabanı örneğinin rolüne taşınır.
Pacemaker hizmeti yeniden başlatılmış eski birincil birincilde otomatik olarak başlatılmazsa, şu şekilde el ile başlattığınızdan emin olun:
sudo service pacemaker start
El ile devralma testi
Pacemaker hizmetini azibmdb01 düğümünde durdurarak el ile devralma test edebilirsiniz:
service pacemaker stop
azibmdb02'de durum
2 nodes configured
5 resources configured
Online: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb02 ]
Stopped: [ azibmdb01 ]
Yük devretme işleminden sonra azibmdb01'de hizmeti yeniden başlatabilirsiniz.
service pacemaker start
HADR birincil veritabanını çalıştıran düğümde Db2 işlemini sonlandırma
#Kill main db2 process - db2sysc
azibmdb01:~ # ps -ef|grep db2s
db2ptr 34598 34596 8 14:21 ? 00:00:07 db2sysc 0
azibmdb01:~ # kill -9 34598
Db2 örneği başarısız olacak ve Pacemaker aşağıdaki durumu bildirecektir:
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Stopped
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Slaves: [ azibmdb02 ]
Stopped: [ azibmdb01 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=157, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:28:19 2019', queued=40ms, exec=223ms
Pacemaker aynı düğümde Db2 birincil veritabanı örneğini yeniden başlatır veya ikincil veritabanı örneğini çalıştıran düğüme yük devreder ve bir hata bildirilir.
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb01 ]
Slaves: [ azibmdb02 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=157, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:28:19 2019', queued=40ms, exec=223ms
İkincil veritabanı örneğini çalıştıran düğümde Db2 işlemini sonlandırma
azibmdb02:~ # ps -ef|grep db2s
db2ptr 65250 65248 0 Feb11 ? 00:09:27 db2sysc 0
azibmdb02:~ # kill -9
Düğüm başarısız duruma geçer ve hata bildirilir
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
rsc_Db2_db2ptr_PTR (ocf::heartbeat:db2): FAILED azibmdb02
Masters: [ azibmdb01 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_monitor_30000 on azibmdb02 'not running' (7): call=144, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:36:59 2019', queued=0ms, exec=0ms
Db2 örneği daha önce atadığı ikincil rolde yeniden başlatılır.
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb01 ]
Slaves: [ azibmdb02 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_monitor_30000 on azibmdb02 'not running' (7): call=144, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:36:59 2019', queued=0ms, exec=0ms
HADR birincil veritabanı örneğini çalıştıran düğümde db2stop force aracılığıyla DB'yi durdurun
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb01 ]
Slaves: [ azibmdb02 ]
kullanıcı db2<sid> execute komutu olarak db2stop force:
azibmdb01:~ # su - db2ptr
azibmdb01:db2ptr> db2stop force
Hata algılandı
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Stopped
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
rsc_Db2_db2ptr_PTR (ocf::heartbeat:db2): FAILED azibmdb01
Slaves: [ azibmdb02 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=201, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:45:25 2019', queued=1ms, exec=150ms
Db2 HADR ikincil veritabanı örneği birincil role yükseltildi.
nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb02 ]
Stopped: [ azibmdb01 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_start_0 on azibmdb01 'unknown error' (1): call=205, stat
us=complete, exitreason='',
last-rc-change='Tue Feb 12 14:45:27 2019', queued=0ms, exec=865ms
HADR birincil veritabanı örneğini çalıştıran düğümde yeniden başlatma ile VM'yi kilitlenme
#Linux kernel panic - with OS restart
azibmdb01:~ # echo b > /proc/sysrq-trigger
Pacemaker, ikincil örneği birincil örnek rolüne yükseltiyor. Vm yeniden başlatıldıktan sonra eski birincil örnek ikincil role geçer ve tüm hizmetler tamamen geri yüklenir.
nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb01 ]
Slaves: [ azibmdb02 ]
HADR birincil veritabanı örneğini çalıştıran VM'yi "durdurma" ile kilitlenme
#Linux kernel panic - halts OS
azibmdb01:~ # echo b > /proc/sysrq-trigger
Böyle bir durumda Pacemaker, birincil veritabanı örneğini çalıştıran düğümün yanıt vermediğini algılar.
2 nodes configured
5 resources configured
Node azibmdb01: UNCLEAN (online)
Online: [ azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb01 ]
Slaves: [ azibmdb02 ]
Bir sonraki adım Bölünmüş beyin durumunu kontrol etmektir. Hayatta kalan düğüm, birincil veritabanı örneğini en son çalıştıran düğümün devre dışı olduğunu belirledikten sonra kaynakların yük devretmesi yürütülür.
2 nodes configured
5 resources configured
Online: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb02 ]
Stopped: [ azibmdb01 ]
Düğümün "durdurulması" durumunda, başarısız düğümün Azure Yönetim araçları (Azure portalı, PowerShell veya Azure CLI'da) aracılığıyla yeniden başlatılması gerekir. Başarısız düğüm yeniden çevrimiçi olduktan sonra Db2 örneğini ikincil role başlatır.
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb02 ]
Slaves: [ azibmdb01 ]