Oracle Clusterware Troubleshooting (Monitoring ve Sorun Giderme)

       
           Oracle Clusterware monitör etmek, problem tespiti ve sorun gidermek aslında cluster servislerini ve alertleri gerektiği gibi yorumlamaktan geçer.Ancak bunların öncesinde cluster sorunlarında aklımızdan çıkarmamız gerekn bir kural vardır.Oracle Clusterda ilk kontrol edilecek olan Cluster node ların system zamanlarının aynı olması yani time synchronization.Eğer network time protocol  (NTP) kullanılıyorsa aşağıdaki gibi time synchronization sağlanabilir.

$ vi   /etc/sysconfig/ntp OPTIONS=”-x  -u  ntp:ntp  -p  /var/run/ntpd.pid”

         Eğer NTP kullanılmıyorsa (CTSS) clusterware synchronization servisi otomatik olarak time seknkronizasyonu yapacaktır.NTP servis service ntpd start komutu ile başlatılır.Ctss servisi ise octcssd.bin daemon process tarafından çalıştırılır.Eğer iki node arasındaki zaman farkı 5 dakikadan fazla ise tüm instance ler kapatılır ve sonrasında system time ayarlamaları yapılır.

Şekil 1:Oracle Clusterware Alert Logs

  

         Logs:
         Şekil 1 de görüldüğü üzere Clusterware servislerine ait loglar ve alert log grid infrastructure kurulduğu yerde ve her bir instanceye ait olarak hostname dosyası altında bulunmuktadır.Şimdi bu loglar hakkında bilgi vermeye çalışalım.

•    CRS logs:    Cluster ready service ye ait loglardır. Bulunduğu yer $GRID_HOME/log/<hostname>/crsd/  şeklindedir. crsd.log dosyaları her 10 MB boyuta ulaştıkça arşivlenmektedir.(crsd.101,crsd102…)

•    Css logs:Cluster synchronization loglarıdır . GRID_HOME/log/<hostname>/cssd/ path altında bulunur. Her 20 Mb de bir arşivlenir.

•    Evm Logs:Event Manager loglarıdır. GRID_HOME/log/<hostname>/evmd/ path altındadır.
Diğer loglarıda şekil 1 deki gibi bulunduğu path altında görebilir ve inceleyebilirsiniz.Tabi bu loğlardan gördüklerinizi yorumlayabilemek için ait oldukları servislere hakim olmanız gerekir.
Diagnostic Collection Script

 GRID_HOME/bin/diagcollection.pl  scripti önemli loğları toplamak için kullanılabilir.Bu scripti kullanabilmek için root yetksisine sahip olmanız gerekmektedir.Çünkü cluster yönetimi root dadır.
Aşağıdaki gibi seçenekleri bulunmaktadır.

GRID_HOME/bin/diagcollection.pl  --collect    logları toplar ve local directory altına atar.
GRID_HOME/bin/diagcollection.pl  --clean           eski loğları temizler     
GRID_HOME/bin/diagcollection.pl  --crs        Crs loğlarını toplar.
GRID_HOME/bin/diagcollection.pl  --core    Core fileleri toplar.
GRID_HOME/bin/diagcollection.pl  --all        Tüm logları toplar.Bu seçenek defaulttur.

           Cluster Verify
           Rac cluster’a eklenmiş farklı bir modül olarak düşünülebilir.Bu modül ile kurulum konfigürasyon ve operasyon işlemlerinde herzaman kontrol etme ve düzeltme işlemleri yaapılabilir.Örneğin fixup opsiyonu ile kurulumda alınana hataları gidermek için script üretilebilir.
Cluvy adından da anlaşılacağı üzere check etmek ve doğrulamak için çok güçlü bir tool dır.Aşağıda Cluster verify utility kullanımına dair örnekler ve opsiyonlar bulunmaktadır. Ayrıca Cluvy comp –list    komutu ile kullaılabilir tüm opsiyonları listeleyebilirsiniz.
Şimdi biz bu opsiyonlardan bazılarının kullanımı hakkında örnek sunalım. Cluvfy komutunun kullanımım hakkında referans olarak kullanabileceğiniz ve syntax örneği görebileceğiniz oracle nin dökümantasyon sayfası mevcuttur.   
http://docs.oracle.com/cd/E14072_01/rac.112/e10717/cvu.htm#CACFJJJD

Kullanımı: cluvfy comp  <komponent-adı> <komponente ait opsiyon>  [-verbose]
Komponetler:
    Nodearch    --Nodeların avail olup olmadığını kontrol eder.   
        cluvfy comp nodereach -n all -srcnode node_to_perform_check  –verbose
    Nodeapps    --node uygulamalarının varlığının control eder
        cluvfy comp nodeapp -n all –verbose
    SCAN        --Scan Konfigurasyonunu kontrol eder
        cluvfy comp scan -verbose

         Resource Debugging

         Resource Debugging Oracle Clusterware kaynaklarını debug etmek ve sorun çözmek için kullanılabilir.Monitor etmede kullanılması doğru değildir.Çünkü performansı etkileyen bir tool dır.Aşağıdaki gibi oracle Clusterware Resource Debugging Enable edilebilir.
crsctl set log resource “resource_name :debugging_level”

    resource_name:Oracle Clusterware kaynak ismi. “crsctl status resource “ komutu ile tüm kaynakların isimleri ve statusleri listelenebilir.
    Debuggin_level:1 den 5 e kadar numara verilir.1 en az ayrıntılı olan debug seviyesidir.

      Kaynağı debug etmenin diğer bir yöntemide <Grid_Home>/log/node1/admin/process_name.ini path altında şeklinde initialization file oluşturmaktır.process_name burada clscfg,css,ons gibi processler olabilir.

    Dynamic Debugging
    Dinamik debug metodu ile bir servise ait istediğiniz modülleri farklı seviyelerde debug etme seçeneğine sahip olabiliriz. Aşağıdaki komutlar dinamik debugging için kullanılabilir.

    crsctl lsmodules css    --css servisine ait modülleri listeler
    crsctl set log css “cssd=2”, “clsf=3” , “skgfd=1”    --css kaynağına ait cssd,clsf,skgdf modüllerini 2,3,1 seviyelerinde debug ediyoruz.

       Cluster Kapanmasına sebep olan yada makinanın reboot olmasına sebep olan problem nedir?
Oracle CLusterware troubleshooting aslında sorun ları tespit edebilme , önceden önlem almak için çalışmalar yapmaktır.Ancak ne kadar monitör edilip önlem alınsada neticede bu bir sistemdir ve bazen istenmeyen şekillerde 1 node reboot olabilir ve cluster kapanabilir.Böyle bir durumda öncelikle servis kesintisi yoksa herşey dışarıdan bakıldığında yolunda gözükmektedir ve bu sevinilecek bir durumdur.Sonrasında ilgili noda tekrar açılır ve servisleri tekrar başlatırsınız.
         Ancak servisler başarılı bir şekilde açılsada problemi monitör etmek , sorunun kaynağını tespit edip çözmek bir daha böyle bir durum yaşamamak için önemlidir.

Peki reboot’a  sebep olabilecek processler  nelerdir?

cclskd: css tarafından kullanılır ve diğer nodalardan bir istek geldiğinde ilgili nodu reboot edebilir.
$<Grid Home>/log/<hostname>/client/oclskd.log     dosyasına bakılabilir.

cssdagent and cssmonitor: Nodeları monitör eden ve clusterware hand eden proseslerdir.
$<Grid Home>/log/<hostname>/agent/ohasd/oracssdagent_root
$<Grid Home>/log/<hostname>/agent/ohasd/oracssmonitor_root

ocssd: Internode arasındaki sağlıklı iletişimi kontrol eder.
$/var/log/messages
$<Grid Home>/log/<hostname>/cssd/ocssd.log         dosyalarına bakılabilir.

hangcheck-timer: Makinanın hang olduğu ve durduğu zamanları monitör eder.
$/var/log/messages

       Ocrdump
        Problem tespitinde yukarıda bahsettiğim yöntemler fiziksel veriler ile iligiliydi.Logical verilerin bilgilerini tutan oc içeriğini ise aşağıdaki metodlarla dump edebilir ve inceleyebiliriz.ocrdump komutu ile alacağımız bu dump dosyları default olarak bulunduğumuz dizine yazılır eğer path vermezsek.Ayrıca root ile alınan ocrdump ve grid ile alınana ocrdump farklıdır.Çünkü cluster yönetimi üzerinde hakları farklıdır.

ocdump file_name_of_text.txt     --ocr içeriğini text dosyasına çıkartır.
Ocrdump –keyname    system.language    --ocr içeriğini belirlenen bir keliem için çıkartır.
Ocrdump  -stdout –xml    --ocr içeriğini bir xml dopsyasına çıkartır.
Ocrdump –backupfile week.ocr     --ocr içeriğini bir backup dosyasına çıkartır.

    Son olarak ocr statusunu kontrol etmek için ocrcheck komutuda kullanılabilir.

                                                                                                        Özcan YILDIRIM