Oracle 11.2 sürümü ile gelen SCAN(Single Class Access Name), küme içindeki her bir düğüm isminin istemciler tarafından bilinmesine gerek kalmadan, en optimal iş yükünün otomatik olarak DBA'ye ihtiyaç duymadan hesaplanarak, istemcinin en uygun düğüme yönlendirilmesini sağlayan bir prosesdir. Bu sayede istemci tarafındaki yük dengelemesi yönetimi DBA ler için ızdırap olmaktan çıkıp, clusterware tarafından otomatik olarak yönetilmektedir. Sunucu tarafındaki yük dengelemesi ise, talep edilen servis için en az yüklü instance bulmak amacıyla SCAN tarafından kontrol edilir ve bu düğümün lokal listenerına bu talep yönlendirilir. Rol bazlı veritabanı servisleri, Oracle Clusterware veya Oracle Restart içerisinden yapılandırılır. Oracle Dataguard, Oracle Clusterware veya Oracle Restart ile etkileşime geçerek primary-standby rol değiş tokuşu sonunda gerekli servislerin aktif olmasını sağlar, böylece sistemi başlatma olayı için herhangi bir trigger yazılmasınada gerek kalmaz. Yapılandırma adımları için daha önceki yazılarıma bakabilirsiniz.
Aşağıdaki örnekte 2 düğümlü RAC adlı primary veritabanında “HR_APP” adlı servis primary rolde aktiftir. 2 düğümlü RACSTD adlı standby veritabanında da “HR_REPORT” adlı servis ise raporlama hizmetleri yapmak üzere fiziksel standby rolünde aktiftir.
[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_APP -l PRIMARY -q TRUE -e SELECT –m BASIC -w 10 -z 150
[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_REPORT -l PHYSICAL_STANDBY -q TRUE –e SELECT -m BASIC -w 10 -z 150
Herhangi bir switchover/failover durumunda HR_APP servisinin primary olarak hizmet vermeye devam etmesi için RACSTD adlı standby veritabanındada aşağıdaki gibi servisler eklenmiştir.
[oracle@linux1_racstand] $ srvctl add service -d RACSTD -s HR_APP -l PRIMARY -q TRUE -e SELECT –m BASIC -w 10 -z 150
[oracle@linux1_racstand] $ srvctl add service -d RACSTD -s HR_REPORT -l PHYSICAL_STANDBY -q TRUE –e SELECT -m BASIC -w 10 -z 150
Fiziksel standby sunucuya redo taşıması yoluyla taşındığından emin olmak için “HR_REPORT” adlı servisin primary veritabanında SRVTL START SERVICE ile başlatılması ve ardından SRVCTL STOP SERVICE ilede durudurulması gerekmektedir.
[oracle@linux1_rac] $ srvctl start service -d RACSTD -s HR_APP
[oracle@linux1_rac] $ srvctl stop service -d RACSTD -s HR_APP
Herhangi bir Dataguard Failover işlemini takiben, Oracle Data Guard Broker hatalı primary veritabanına bağlantıları temizlemesi için otomatik olarak FAN(Fast Application Failover) olayı yayınlar. Olayın alımını takiben FAN alım aboneleri yeni primary veritabanında başlayan servise otomatik olarak yeniden bağlanırlar.
Kusursuz uygulama(application) failover işlemi disk arızası, data bozulması, donanımsal arıza, programın askıda kalması gibi oldukça sık maydana gelebilecek lokal arızalar durumunda oldukça elverişlidir. Kusursuz uygulama failover işleminde 3 ana parka vardır.
- Yeni primary sitede/sunucuda servislerin yeniden başlatılması
- Uygulamaları mevcut bağlantılarını sonlandırması için bilgilendirme
- En elverişli şekilde uygulamaların yeniden bağlantı açmasını sağlama
Kusursuz uygulama failover işlemi için cluster ortamında Oracle Clusterware, tekil instance ortamında Oracle Restart olmalı ve her iki durumdada DataGuard Broker aktiveli Oracle DataGuard yapılandırmasına ihtiyaç duyulmaktadır.
JDBC uygulamalarında kusursuz application failover yapılandırması
- Uygun servis hem primary hemde standby sitede oluşturulmalıdır.
Servislerin gerek normal çalışma durumunda primary sitede primary rolde işlem yapması, gerekse herhangi bir switchover/failover durumunda yeni primary rolüne geçen clusterdada primary rolde başlaması için primary ve standby cluster içinde ilgili servisleri oluşturuyoruz. TAF ve OCI HA olaylarını devredışı bırakıyoruz(kırmızı kısımlar).
Primary cluster içinde;
[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_APP -r linux1_rac, linux2_rac -l PRIMARY -q FALSE -e NONE -m NONE -w 0 -z 0
[oracle@linux1_rac] $ srvctl add service -d RAC -s HR_REPORT -r linux1_rac, linux2_rac -l PHYSICAL_STANDBY -q FALSE -e NONE -m NONE -w 0 -z 0
Standby cluster içinde:
[oracle@linux1_racstand] $ srvctl add service -d RAC -s HR_APP -r linux1_racstand, linux2_racstand -l PRIMARY -q FALSE -e NONE -m NONE -w 0 -z 0
[oracle@linux1_racstand] $ srvctl add service -d RAC -s HR_REPORT -r linux1_racstand, linux2_racstand -l PHYSICAL_STANDBY -q FALSE -e NONE -m NONE -w 0 -z 0
Servisleri oluşturduktan sonra HR_REPORT servisinin primaryden standby siteye redo taşımasını başlatması için primary sitede SRVCTL START SERVICE ile başlatılmalıdır.
[oracle@linux1_rac] $ srvctl start service -d RACSTD -s HR_APP
- Oracle JDBC sürücüsü yüklenmelidir. Her bir site için SCAN adresi içerecek adres listesini taşıyacak olan bağlantı tanımlayıcısının kullanılması gerekmektedir. Aşağıdaki örnek HR_APP uygulaması içindir.
Eğer
"jdbc:oracle:thin:@" + "(DESCRIPTION_LIST=" +
"(LOAD_BALANCE=off)" + "(FAILOVER=on)" + "(DESCRIPTION=" + "(ADDRESS_LIST=" + "(LOAD_BALANCE=on)" + "(ADDRESS=(PROTOCOL=TCP)(HOST=rac-scan)(PORT=1521)))" + "(CONNECT_DATA=(SERVICE_NAME=hr_app)))" + "(DESCRIPTION=" + "(ADDRESS_LIST=" + "(LOAD_BALANCE=on)" + "(ADDRESS=(PROTOCOL=TCP)(HOST=racstd-scan)(PORT=1521)))" + "(CONNECT_DATA=(SERVICE_NAME=hr_app))))";
JDBC URL üzerinden yapılan bağlantı sonrasında Oracle NET servisi DNS ile iletişime geçerek RAC primary sitesinin SCAN adresini toplam 3 IP adresine çözümler. Rastgele bir tanesini seçerek bağlantı sağlar.Eğer primary üzerine bağlantı başarısız olursa bu durumda RACSTD standby sitesindeki SCAN üzerinden rastgele bir tanesi üzerinden bağlantı sağlar.
Eğer TCP_CONNTIMEOUT_STR özelliği ayarlanırsa, JDBC istemcisi çok kolay bir şekilde adres listesine taşınır.
Properties prop = new Properties();
prop.put(oracle.net.ns.SQLnetDef.TCP_CONNTIMEOU T_STR, ""+5000); // 5000ms
pds.setConnectionProperties(prop);
Fast Connection Failover işlemini aşağıdaki adımlarda anlatıldığı şekilde aktive ediyoruz.
- Bu işlem için ONS(Oracle Notification Services) tüm düğümlerde aktif olmalıdır. Tüm düğümlere ONSCTL PING komutuyla ping çekiyoruz ve ONS nin aktif olup olmadığını kontrol ediyoruz. ONSCTL PING komutunun cevap vermediği düğümlerde sırasıyla komutlarını çalıştırırak ONS servisini kuruyoruz.
$ srvctl add ons
$ srvctl enable ons
$ srvctl start ons
- Eğer application tier ONS üzerinde çalışıyorsa cluster düğümlerini application ONS ye duyarlı hale getiriyoruz. ORA_CRS_HOME/bin/racgons dizini altından aşağıdaki komutu primary ve standby sitelerde çalıştırıyoruz.
# racgons.bin add_config linux1_rac:6200 linux2_rac:6200 linux1_racstand:6200 linux2_racstand:6200
- Veri kaynağı üzerinde setFastConnectionFailoverEnabled(true) parametresi ile Fast Connection Failover işlemini ayarlayarak uygulamanın hem primary hemde standby sitedeki ONS bekletici programlarına(daemons) bağlanma işlemini tamamlıyoruz.
ods.setConnectionCachingEnabled(True);
Properties prop = new Properties();
prop.setProperty("MinLimit", "5");
prop.setProperty("MaxLimit", "40");
prop.setProperty("InitialLimit", "10");
ods.setConnectionCacheProperties(prop);
ods.setFastConnectionFailoverEnabled(True);
ods.setConnectionCacheName(“MyCache”);
ods.setConnectionCacheProperties(cp);
ods.setONSConfiguration("nodes= linux1_rac:6200,linux2_rac:6200, linux1_racstand:6200,linux2_racstand:6200");
Kayıtlar
0 yorum:
Yorum Gönder