Weblogic Versiyonlu Deploy

Weblogic server side-by-side (çalışan bir kod varken, aynı kodun farklı bir versiyonunu deploy etme)  adı verilen son derece faydalı bir deployment seçeneği sağlamaktadır. Bir uygulamanın yeni bir versiyonunu devreye almak ve aynı zamanda eksi versiyondaki uygulamanın çalışır durumda kalmasını istiyorsanız side-by-side deployment tam da sizin aradığınız bir çözüm olacaktır. Eski versiyonu kullanan sessionlar expired olduğunda weblogic bunu anlayarak eski versiyonlu uygulamayı deaktif duruma getirecektir. Aynı anda, yeni versiyona sahip olan uygulama aktif olacak ve tüm yeni sesionlar da bu uygulamaya bağlanacaktır.

Bir uygulamaya versiyon tanımlayıcısı atamak için, uygulamanın bir parçası olan MANIFEST.MF dosyasına sürüm adını veren bir satır ekleyebilirsiniz. Alternatif olarak sürüm adı, dağıtım sırasında weblogic.Deployer komut satırı aracının -appversion argümanı veya WLST komutlarının deploy () ve updateApplication () ‘nin archiveVersion argümanı kullanılarak belirtilebilir.

Eğer aşağıdaki gibi bir manifest dosyasını uygulama içerisine META-INF/MANIFEST.MF dosyası olarak daha ilk deployment aşamasında uygulama versiyonlanmış olacaktır.

cat /u01/deploy/deployversion1/simple/META-INF/MANIFEST.MF
Manifest-Version: 1.0
Class-Path:
Created-By: Bill Bell
Weblogic-Application-Version: v1

Eğer aşağıdaki gibi bir sonraki güncel uygulamada (Yani bu örnek için ‘v2’) versiyon bilgisi değişirse, Weblogic bu durumdan da haberdar olacak ve hem mevcuttaki uygulamanın hem de güncel uygulamanın admin kontrolünde birlikte yaşamasına imkan tanıyacaktır.

cat /u01/deploy/deployversion2/simple/META-INF/MANIFEST.MF
Manifest-Version: 1.0
Class-Path:
Created-By: Bill Bell
Weblogic-Application-Version: v2

Bilinen yöntemlerle bu uygulamanın deploymentı yapılır.

Bu aşamada daha önce karşımıza çıkmayan ‘Archive Version’ etiketi ile de artık karşılaşmış oluyoruz. Weblogic, uygulama içerisine gömmüş olduğumuz manifest dosyası içerisindeki versiyon bilgisini okuyarak uygulamayı versiyonlamış oldu.

 

Aslında versiyon bilgisinin alınması dışında şu aşamaya kadar farklı birşey ile karşılaşmadık. İlgili IP:Port üzerinden uygulamayı çağıracak olursak mavi görüntülü ilk versiyon ile uygulamayı açmış oluruz.

Bu aşamada artık mevcutta var olan uygulamayı yeni versiyon ile update etmeye başlıyoruz.

 

Yeni versiyonu deploy ederken dikkat edilmesi gereken bir önemli nokta eski ve yeni versiyon uygulamaların disk sistemi üzerinde ayrı ayrı path’lerde aynı isimle bulunmalarıdır. Eğer yeni versiyon, mevcut uygulamanın üzerine yazılacak olursa update sonrası rollback imkanımız kalmamış olur ve update özelliğinden faydalanılamaz.

Yeni versiyon algılandı.

 

Tam bu aşamada daha önce görmeye alışık olmadığımız bir görüntü ile karşılaşıyoruz. Aynı hedef (Managed server, cluster, …) üzerinde aynı isimli iki farklı uygulama aynı anda bulunuyor.

 

Test edersek;

Deployment tamamlandıktan kısa bir süre sonra ilk eski versiyonun state’inin artık ‘stop Running’ olarak işaretlendiği görülür.

Artık yeni uygulama ‘Active’ olmuştur. Fakat her iki versiyon da halen ekranda görülmeye devam eder.

Bu aşamada yeni versiyonu yalnızca admin isteklerine açabilir testlerinizi yaptıktan sonra tüm kullanıcıların hizmetine sunabilirsiniz. Ya da eğer testleriniz başarısız olduysa eski pakete dönme imkanınız da halen mevcut. Eski pakete dönülmesi için yapılması gereken yalnızca ilk versyonun kendisi üzerinden update/re-deploy edilmesidir.

NOT: Weblogic server maksimum 2 farklı versiyonu deploy etmenize izin verir.

war dosyalarını indirmek için bağlantıya tıklayabilirsiniz.

Mustafa Bektaş Tepe
İyi Çalışmalar

Loading


Weblogic Instance Açılışında Performans Artışı

Weblogic üzerinde bazen servislerimizin beklenenden yavaş açıldığını , açılsa dahi ” 7001/console ”(Admin Console) ekranın beklettiğine şahit olmuşsunuzdur.

Managed server ları restart edip log akışını izlerken bazı platformlarda logumuzun uzun süre aşağıdaki satırda beklediğinide görebiliriz:

#### < xapp-1-7003> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1329309449456>

Bunun nedeni, rasgele sayı üretimi için kullanılan JVM librarysi UNIX platformları için varsayılan olarak /dev/random’a dayanmaktadır. Bu, bir sonuç döndürmeden önce başlatmayı yavaşlatabilir. Bu da genelde servislerin açılmasında gecikmelere sebep olabilmektedir. “dev/random” komutu daha güvenli olmasına karşın unix platformlarda gecikmeye sebep oluyorsa, bunun yerine “dev/urandom” komutunun kullanılması önerilmektedir.

Platformumuzda bu performans probleminin olup olmadığını test etmek için, shell prompt da aşağıdaki komutun çıktısı kontrol edilir.

[root@test ~]# time head -1 /dev/urandom
±›Zµ3cİ©ŠÔ‹i91D¹

real 0m0.002s
user 0m0.000s
sys 0m0.002s
[root@test ~]# time head -1 /dev/random
.......

real 2m50.623s
user 0m0.002s
sys 0m0.003s

Gördüğümüz gibi, /dev/urandom hemen sonucu döndürürken, /dev/random neredeyse 3 dakika sürdü.

Weblogic sunucusunu başlanamasını hızlandırmak için ise JVM’in java.security ayarını değiştiririz.

[root@admin ~]$ vi $JAVA_HOME/jre/lib/security/java.security
...
securerandom.source=file:/dev/urandom

Yada sadece belirli bir domain için java.security parametresini değiştirmek istersek, startWebLogic.sh scriptini güncelleriz;

[oracle@test ~]$ vi $DOMAIN_HOME/bin/startWebLogic.sh
#!/bin/sh
export JAVA_OPTIONS=-Djava.security.egd=file:/dev/./urandom
...

Mustafa Bektaş Tepe
İyi Çalışmalar

Loading



Veritabanında Denetleme (Audit)

Veritabanında standart denetleme audit_trail parametresine değer (os, db, db extended, xml, xml extended) atanması ile başlar. Eğer denetlemeyi durdurmak istersek parametre NONE yapılmalıdır. Bu parametrenin none yapılması ile beraber veritabanı kapatılıp açıldığında tüm denetleme durmuş olur.

Denetlemeler komut, yetki, obje ve network aktiviteleri bazında tanımlanır. Denetleme başlatmak için AUDIT, durdurmak için NOAUDIT komutu kullanılmalıdır.

Bir kullanıcı kendine ait tüm kullanıcılar üzerinde AUDIT başlatabilir. Başka kullanıcıların objeleri üzerinde AUDIT başlatmak için ise AUDIT ANY yetkisi olmalıdır. Sistem yetkileri üzerinde AUDIT tanımlamak için AUDIT SYSTEM yetkisi olmalıdır. NOAUDIT komutunun çalıştırılması için ise özel bir yetkiye gerek yoktur.

O7_DICTIONARY_ACCESSIBILITY parametresi FALSE ise denetim izleri yalnızca SYSDBA yekili kullanıcılar tarafında silinebilir. DELETE ANY TABLE yetkisine sahip kullanıcılar dahi silemezler.

Tüm denetim kayıtları herhangi bir transaction’ın tanımlanmasını beklemeden, denetlenecek komutun çalışma anında yazılır.

Komutların Denetlenmesi

Komut bazında denetleme yapılması, kullancıların çalıştırdığı,

  • DML(INSERT, UPDATE, DELETE, SELECT)
  • DDL(CREATE, DROP….)

gibi veritabanı komutlarının denetlenmesi işlemidir. Denetleme yaparken denetleyeceğimiz obje türünü girmemiz yeterlidir. AUDIT komutunda yazdığınız obje türüne türüne göre istenilen komutlar denetlenir. Obje türüne göre denetleyebileceğimiz komutlar aşağıdaki gibidir.

Oracle Audit System

 

 

 

 

 

 

 

Bu tür komut bazlı denetlemeyi başlatmak için AUDIT SYSTEM yetkisine sahip olunması gerekir. (dba_sys_privs viewi sorgulanarak yetki sahipleri bulunabilir) Komut bazında denetleme yeni session açıldığında aktif olur.

Örneğin tablo objesi DELETE komutunun tüm veritabanında denetlenmesi için aşağıdaki komutu çalıştırabiliriz.

audit delete table by access;

Yada sadece SYSTEM kullanıcısında çalıştırılan SELECT TABLE komutunu denetlemek istersek aşağıdaki komutu çalıştırabiliriz.

audit select table by system;

Verilen audit leri görmek için DBA_STMT_AUDIT_OPTS viewini sorgulayabiliriz.

Oracle Audit Privilege

 

 

Yukarıdaki resimdede görüldüğü gibi;

  • SYSTEM kullanıcısında çalışan tüm SELECT TABLE komutları
  • SYSTEM kullanıcısının çalıştırdığı tüm komutların
  • EXEMPT ACCESS POLICY yetkisini veren GRANT komutlarının
  • Bütün kullanıcılarda olmak üzere DELETE TABLE komutlarının denetlendiğini görmekteyiz.

(devamı..)

Loading


Oracle Audit – Denetim İzlerinin Yönetilmesi

Denetim izleri yapılan konfigürasyona göre veritabanında tablo olarak veya işletim sisteminde dosya olarak tutulmaktadır. Bu denetim izlerini silmek veya başka ortamlara taşımak için farklı yöntemler kullanılabilir. Fakar Oracle 11g ile beraber denetim izlerinin yönetilmesi için DBMS_AUDIT_MGMT paketi kullanılmaya başlanmıştır. Böylece değişik ortamlarda tutulan denetim izleri tek bir paket ile yönetilebilir hale gelmiştir. DBMS_AUDIT_MGMT paketi denetim izleri üzerinde taşıma silme işlemi yaparken veritabanındaki sessionları bekler duruma getirmez ve kullanıcılar çalışmalarına kesintisiz devam ederler. Bu nedenle değişik yöntemler ile denetim izlerini yönetebilmemize rağmen(Örneğin tabloda ise DELETE komutu, işletim sisteminde ise rm komutu kullanabiliriz) DBMS_AUDIT_MGMTpaketini kullanmak daha doğrudur.

Veritabanında Saklanılan Denetim İzlerinin Farklı Tablespacelere Taşınması

Veritabanında tutulan standart denetim izleri SYS.AUD$ tablosunda, ayrıntılı denetim izleride(Fine Grained Auditing-log mekanizması diyebiliriz) FGA_LOG$ tablolarında tutulur. Veritabanı ilk yaratıldığında bu tablolar varsayılan olarak SYSTEM tablespace’inde tutulur. Ama tabloların büyümesi ve denetleme politikası nedeniyle SYSTEM tablespace üzerinde baskı oluşabilir. Bu nedenle sık sık silinmesi ve sürekli ekleme yapılan tabloları ayrı bir tablespace’e taşımak isteriz.

Bu işlem DBMS_AUDIT_MGMT.set_audit_trail_location veritabanı paketi ile yapılır. Bu paket 2 tane parametre alır. Bir tanesi taşımak istediğiniz tablo türünü gösteren parametre, diğeri ise tabloların taşınacağı tablespace adıdır.

Tablo türünü gösteren parametre aşağıdaki 3 değerden birini alır.

  • DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: Standard denetim izi (AUD$).
  • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Ayrıntılı enetim izi (FGA_LOG$).
  • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD : Standart ve Ayrıntılı denetim izi için.
SELECT table_name, tablespace_name
FROM dba_tables
WHERE table_name IN ('AUD$', 'FGA_LOG$')
ORDER BY table_name;
TABLE_NAME   TABLESPACE_NAME
------------------------------ ------------------------------
AUD$            SYSTEM
FGA_LOG$        SYSTEM

CREATE TABLESPACE AUDIT_TS
DATAFILE
'/u01/app/oracle/oradata/ORCL/AUDIT_TS' SIZE 104857600 AUTOEXTEND ON NEXT 10485760 MAXSIZE UNLIMITED;


BEGIN
DBMS_AUDIT_MGMT.set_audit_trail_location(
audit_trail_type = DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
audit_trail_location_value = 'AUDIT_TS');
END;
/


SELECT table_name, tablespace_name
FROM dba_tables
WHERE table_name IN ('AUD$', 'FGA_LOG$')
ORDER BY table_name;
TABLE_NAME   TABLESPACE_NAME
------------------------------ ------------------------------
AUD$           AUDIT_TS
FGA_LOG$       SYSTEM


BEGIN
DBMS_AUDIT_MGMT.set_audit_trail_location(
audit_trail_type = DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD,
audit_trail_location_value = 'AUDIT_TS');
END;
/


SELECT table_name, tablespace_name
FROM dba_tables
WHERE table_name IN ('AUD$', 'FGA_LOG$')
ORDER BY table_name;

TABLE_NAME  TABLESPACE_NAME
------------------------------ ------------------------------
AUD$         AUDIT_TS
FGA_LOG$     AUDIT_TS

(devamı..)

Loading


Oracle Audit

Denetleme en genel tanımıyla, veritabanında yapılan işlemlerin belirlenmiş kurallara göre izlenmesi ve kayıt edilmesidir.

Veritabanı denetlemesi veritabanı güvenliği açısından en önemli çalışmalardan bir tanesidir. Veritabanı denetlemesi sayesinde;

  • Veritabanında bulunan bilgilerin tutarlı olduğu,yetkisiz kişilerce değiştirilmediğini kanıtlar.
  • Veritabanında yapılan şüpheli hareketler sorgulanabilir ve kimin tarafından yapıldığı bulunur.
  • Veritabanında yetkisiz işlem yapmak isteyen kullanıcılar açısından caydırıcı önlem alınmış olur.
  • Güvenlik yönetmeliklerine uyum sağlanır.
  • Veritabanı performansı ile ilgili bilgiler toplanır.

Burada önemli noktalarda bir tanesi hangi kurallara göre izleme ve kayıt yapılacağımızın belirlenmesidir. Veritabanında kısa bir süre içerisinde milyonlarca işlem olabilir. Önemli olan kayıt altına alınmaya değer işlemlerin belirlenmesidir. Kayıt altına alınması gereken işlemlerin belirlenmesi  bizim denetleme politikamıza (Auditing Policy) bağlıdır.

Diğer önemli bir nokta ise, veritabanındaki işlemlerin nasıl kayıt altına alınacağıdır. Bu kayıtlara denetim izi denmektedir.

Bunun yanında diğer bir önemli noktada denetim izlerinin değiştirilmeden saklanmasının sağlanmasıdır.

Oracle Veritabanında Mutlaka Tutulan Denetim İzleri

Oralce veritabanında denetim tamamen kapansa bile zorunlu kayıt altına alınan 3 tane işlem vardır.Bunlar;

  • Veritabanı açılışı
  • Veritabanı kapatılışı
  • SYSDBA ve SYSOPER rolüne sahip kullanıcıların veritabanına bağlanması

Veritabanında denetim izleri iki ayrı parametre ile yönetilmektedir. Bunlar audit_trail ve audit_sys_operations parametreleridir. Bu paramrelerden audit_trail parametresine NONE, audit_sys_operations parametresine boşluk atarsak veritabanında denetlemeyi durdurmuş oluruz.

Bu durumda olan bir veritabanında, yanlızca veritabanı kapama, açma ve veritabanı yöneticisi login işlemleri, denetim izi olarak audit_file_dest dizininde bulunan *.aud dosyalarına yazılır.
(devamı..)

Loading


  • Sertifikasyon



  • Etiketler

  • Topluluklar

                     
                     
  • Copyright © 1996-2010 Mustafa Bektaş Tepe. All rights reserved.
    Türkçeleştirme Blogizma | AltyapıWordPress