Oracle 10g RAC mimarisinde yük dengeleme 2 farklı yoldan yapılandırılabilir. Bunlar;
- İstemci tarafında bağlantıları dengeleme
- Sunucu tarafında bağlantıları dengeleme
Şimdi bu her iki yük dengeleme metodunun farklılıkları ve performans üzerindeki etkilerini örneklerle inceleyelim.
- İstemci tarafında bağlantıları dengeleme
Birden fazla düğümlü Oracle RAC mimarisi kurulumunun en büyük sebeplerinden biri istemci bağlantılarının farklı düğümler üzerine dağıtılarak dengelenmesidir. Burada paketler eşit olarak dağıtılamayacaktır, ancak yapılan bağlantılar toplam sayı bazında mevcut düğümlerde dengelenecektir. Bu işyükünü RAC platformunda dengelemek için düğümlerdeki tnsnames.ora dosyalarında bir takım parametre değişiklikleri yapılmalıdır.
RAC =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2)(PORT = 1521))
(LOAD_BALANCE = ON)
(FAILOVER = ON)
(CONNECT_DATA =
(SERVICE_NAME = RAC)
(FAILOVER_MODE = (TYPE = SELECT)(METHOD = BASIC))
)
)
LOAD_BALANCING değerinin ON olarak atanması sonucunda Oracle Net servisi çeşitli listener’lar içinden rastgele bir düğüm adresi seçerek bağlantıyı sağlar. Eğer
- Sunucu tarafında bağlantıları dengeleme
Sunucu tarafında bağlantıları dengeleme, istemci tarafında bağlantıları dengelemeye nazaran çok daha avantajlıdır. Listener tarafında işlem gördüğünden dolayı o an ne kadar oturum askıda kalmış veya ne kadar bağlantı düğümlere yönlenmiş sorularının cevaplarını bilir ve böylece etkili bir yük dengeleme sunar.
Bu noktada RAC ortamında servis kavramını netleştirmek gerekmektedir.Servis, tek bir instance içinde ve çoklu instance ve veritabanları üzerinden çalışan rakip uygulamaları yönetmek için tek sistem imajı sağlar. Servisler performans iyileştirme üzerinde farklı bakış açıları sunar. Servisler ile tüm işyükleri görülür ve ölçülebilir. Servisler öylesine dinamiktirki, yük arttığında bu servislerin çalıştığı instance sayısı arttırılabilir veya yük azaldığında azaltılabilir.Bu dinamik kaynak tahsisi, beklemeler meydana geldiğinde maliyeti azaltan sonuçlar verebilmektedir.
Servisler lokasyon bağımsızdır ve bunu yapılandırmak için RAC HA frameworku kullanılır. İşyükü dengelemesi ve servislerin özelliklerinin süreklilik durumu için, Oracle Clusterware her bir servisin HA konfigürasyonunu Oracle Cluster Registry(OCR) içinde saklar. HA konfigürasyonu, her bir servisin desteklediği tercih edilen ve uygun instance setlerini tanımlar. Tercih edilen instance seti ilgili servisin desteklediği instance sayısını tanımlar.
Uygun instance başlangıçta servisi desteklemez. Ancak, tercih edilen instance servisi destekleyemediği zaman bu servis için bağlantıları kabul Eğer
RAC için en uygun servis yapılandırmaları
- Aktif/Yedek: Birincil ve ikincil(yedek) olarakta adlandırılabilecek en basit servis yapılandırma türüdür.
- Aktif/Simetrik: Aynı servis setleri tüm instance’lerde aktifdir. Her instance, servis yük paylaşımı ve servis yük devretme yeteneğine sahiptir.
- Aktif/Asimetrik: Bu servis yapılandırmasında düşük kapasite ihtiyacındaki servisler tek kardinelite ile tanımlanır ve bir çökme olayına karşılık her bir servis, sürdürülürlüğün sağlanması amacıyla farklı instanceler üzerine serpiştirilmiştir. En az üçlü cluster instance lerde tanımlanabilir.
Sunucu tarafında bağlantıları dengelemenin yapılandırması adımları altta yer almaktadır.
- Oracle 10g Release 2 itibariyle RAC içinde yük dengeleme tavsiyecisi adını verdiğimiz OCI, OCP.NET ve JAVA bağlantı havuzlarına bilgi aktaran bir iyileştirici servis vardır. Oracle Notification Service(ONS) sayesinde üçüncü parti yazılımlar yük dengeleme tavsiyecisine kendilerini kaydederler.Bu tavsiyeci, instance içindeki her bir servis için mevcut iş yükünü izler ve servisi sağlayan instancelerden birisinin konfigürasyonu veya statusu değiştiğinde bağlantı havuzlarına göndermek üzere FAN olayları oluşturur. Bu da bağlantı havuzlarına yeni bir bağlantı oluşturacağı zaman en ilişkili instance’ı seçme imkanı verir. Bu amaçla kullandığımız uygulama katmanına en fazla verim sağlayacak olan yük dengeleme hedefleri ve bağlantı dengeleme hedeflerinin neler olduğuna bakmamız ve hangisini kullanmanın en etkili yol olduğuna karar vermek gerekmektedir.
Yük dengeleme hedefleri;
GOAL_NONE: Yük dengeleme tavsiyecisini devre dışı bırakır. Bu durumda her bir servis için toplam oturum sayısı üzerinden yük dengeleme hesabı yapılır.
GOAL_SERVICE_TIME: Yük dengeleme tavsiyecisinin, servis tarafından tamamlanan iş esnasında geçen zaman ile beraber bu servis için uygun bant genişliğini gösterir. Kısa bir süre içinde işyükü dramatik olarak değişen servisler için uygundur(onlşne alışveriş siteleri gibi)
GOAL_THROUGHPUT: Yük dengeleme tavsiyecisinin, servis tarafından tamamlanan tüm işlerin ağırlıklı hareket ortalamasını çıkarak işlerin zamanında tamamlanma oranını belirler ve bu servisler için uygun bant genişliğinide ilave ederek değeri ortaya çıkarır. Seri olarak çalışmak üzere kuyruğa alınan uzun süreli görevler için uygundur(büyük partiler halinde işlemleri çalıştıran zamanlanmış görevler gibi)
Her bir servis için bağlantı dengeleme hedefleri;
CLB_GOAL_LONG: Servis başına oturum sayısını kullanarak bağlantı sayılarını dengeleme. Uzun süre bağlantıya ihtiyaç duyan OLTP gibi uygulamalar için çok elverişlidir.
CLB_GOAL_SHORT: GOAL_SERVICE_TIME veya GOAL_THROUGHPUT etkin ise yük dengeleme tavsiyecisini kullanmaktadır. Web uygulamaları gibi kısa süreli bağlantıya ihtiyaç duyulan sistemlerde etkinleştirilmesi uygundur.
Yük dengeleme hedefi ve bağlantı dengeleme hedefi DBMS_SERVICE paketi içinde CREATE SERVICE veya MODIFY SERVICE prosedürleri ile atanabilir. DBCA ile RAC veritabanı kurulduğunda varsayılan olarak sunucu tabanlı yük dengeleme etkin, ancak tavsiyeci devredışıdır (yani GOAL_NONE ve CLB_GOAL_LONG varsayılan parametrelerdir).
Mevcut servis için parametreleri değiştirmek için ise alttaki kullanılır.
SQL> EXECUTE dbms_service.modify_service -
> (service_name => 'SERVICE1', -
> goal=> DBMS_SERVICE.GOAL_SERVICE_TIME, -
> clb_goal => DBMS_SERVICE.CLB_GOAL_LONG);
Mevcut parametre değerlerini görmek için ise alttaki sorgu kullanılabilir.
SQL> SELECT name, goal, clb_goal FROM dba_services;
Yeni bir servis oluştururken istediğimiz bir değeri atayabiliriz. Alttaki senaryoda yük dengeleme hedef tavsiyecini servis zamanlarını referans alarak aktive ediyor ve bağlantı dengeleme için ise KISA zaman aralığını seçerek SERVICE2 adında yeni bir servis oluşturuyoruz.
SQL> EXECUTE dbms_service.create_service -
> (service_name => 'SERVICE2',network_name => 'SERVICE2', -
> goal=> DBMS_SERVICE.GOAL_SERVICE_TIME, -
> clb_goal => DBMS_SERVICE.CLB_GOAL_SHORT);
Bu yeni eklenen servisi istediğimiz instancelere eklemek ve başlatmak için ise;
$ srvctl add service -d RAC -s SERVICE2 -r "RAC1" -a "RAC2"
** Burada –r bağlacı tercih edilen instance, -a bağlacı ise uygun instance için kullanılmaktadır. –a bağlacı opsiyone, -r bağlacı zorunludur. **
$ srvctl start service -d RAC -s "SERVICE2"
$ srvctl stop service -d RAC -s "SERVICE2"
Servislerin çalışıp çalışmadığını test etmek ve etkinleştirmek/devredışı bırakmak için ise;
$ srvctl status service -d RAC -s "SERVICE1,SERVICE2"
Service SERVICE1 is running on instance(s) RAC1, RAC2
Service SERVICE2 is not running
$ srvctl enable service -d RAC -s SERVICE2 -i RAC2
$ srvctl disable service -d RAC -s SERVICE2 -i RAC2
Servisi tüm instancelerden kaldırmak için ise;
$ srvctl remove service -d RAC -s SERVICE2
- İstemcilerin oluşturulan servisi kullanabilmesi için servisin tnsnames.ora dosyasına eklenmesi gerekmektedir. Alttaki örnekte SERVICE2, rac1 ve rac2 hostlarda çalışması için tnsnames.ora dosyasına ekleniyor. Burada, herhangi bir düğüm veya instance çökme durumlarında veritabanı servisinin otomatik ayağa kalkması için host’un public ip adresi yerine, VIP adresinin tanımlı olmasına dikkat edilmesi gerekmektedir.
SERVICE2 =
(DESCRIPTION =
(LOAD_BALANCE = yes)
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
(CONNECT_DATA =
(SERVICE_NAME = SERVICE2)
)
)
Kayıtlar
0 yorum:
Yorum Gönder