• Control-M/EM  kullanıcıların login oldukları, serverları ve agentları gözlemledikleri, JOB’ların statuslarını görüntüledikleri makinadır.
• Scheguling engine ile JOB’lar order edilir.
• Control-M Agent JOB’ları Submit eder.
• Server ile Agent arasında iki iletişim yöntemi vardır. Biri Transient diğeri Persistent.

Transient : JOB order edildiği zaman, 7006 portundan agent’a erişilerek JOB order edilir.

İstek agent tarafından alındıktan sonra connection kapatılır. Sonrasında JOB çalıştırılır. Takibi sağlanır. Feedback için 7005 portundan connection açar. Feedback bilgisine ulaştıktan sonra portu kapatır. Transient default olarak gelen connection çeşitidir. Portlar değiştirilebilir.

• Persistent: Connection 1 kere açılır ve yeniden kapatılmaz. Sabit bir connection’dır. Tek bir 7006 portu üzerinden çift yönlü iletişim sağlanır.  Server, Agent’ın router’ı ile muhattap olur.
• CCM : Control-M compantentlerini yönetmemizi sağlayan interface’dir.
• Ctmagcfg : Agent’ın configini sağlayan command-line utilty’dir.
• Ctm_menu: Hem server hemde agent için configi sağlayan command-line utilty’dir.
• Netstat/telnet : uzak bilgisayara bağlantı sağlayan command-line aracı telnettir. Firewall’ın bloklayıp bloklamadığını Telnet aracılığıyla anlayabiliriz. Netstat network istatistiklerini gösterir. İlgili host’a listining durumda olan portları gösterir.

Agent Communication Seneryolar

SENARYO 1 : Yeni bir agent kurulumu sonrasında JOB’lar order edilebilmekte, Ama feedback 10 dk geç alınıyor.

Eğer Agent ile Server arasında bir firewall varsa veya configlerinde bir yanlışlık varsa, agent server’a connection açamayacak ve JOB durumlarını iletemeyecek.

Bu yüzden Agent üzerinden ag_diag_comm command-line a yazıldı. Çıkan sonuçlarda agent portunun yanlış olduğu ortaya çıktı.

Server tarafında ctm_diag_comm “agentadı” yazıldı.  Portunların yanlış olduğunu farketti. Agent tarafında yanlış ayarlanmıştı. CCM üzerinden çözüldü.

SENARYO 2 : Bir Agent’a erişilemiyor. JOB Submit edilemiyor.

Ag_diag_comm yapıldı. Persistent bağlantı çeşiti olduğu görüldü. Fakat iki farklı port tanımlandığı için düzgün çalışmamaktadır. Çünkü Persisttent bağlantı tek bir port üzerinden yürür.

Ag_diag_comm ve ctm_diag_comm komutları uzun süre cevap dönmediler. Bu sebeple portların denenmesi için öncelikle telnet yapıldı ( server tarafında ). Agent’ın olduğu makinada 7006 portuna bağlanmayı denediğinde connection refulse hatası aldı.

Telnet agentname 7006

Sonra başka cmd üzerinden ( Server ) 7006 portunu dinleyecek komutu yazdı.

Netstat -an | find /I 7006  –> sonucunda geriye bir cevap dönmedi.

Agent’ı start etti servisvices.msc ye girip Control-M/Agent servisini başlattı.

Agent server’ın yetkisiz olduğuna dair mesaj döndü. Lütfen server’ı yetkili serverlar listesine ekleyin.

Agent üzerinde ctmagcfg yi çalıştırdı.  4 numarayı seçerek autorized server host adını değiştirdi .

Sonuç: Transient connection minimum 2 connection Persistent minimum 1 connection gerektirir.

Persistent connection bir kere açıldığında yeniden kapanmayacaktır. Transient ise JOB order edildiğinde Agent tarafından JOB statusu feedback olduğunda Server tarafından kapatılır.

The post Agent Communication & Configuration | Control-m #15 appeared first on Dinamik Network.

Bu portlar istenirse değiştirilebilir. 7006 portu bidirectional ( çift yönlü ) olarak kullanılır. Connection bir kere açılır ve kapatılmaz.

Job öncelikle serverdan agent’ın routerına iletilir. Router Listener’a gönderir. Listener Job’u submit eder. Tracker Job’un stat’ını Monitoring eder ve Info’yu router’a döner. Router Info’yu agent’a gönderir.

Agent Connectivity Configuration

CCM: Control-M Configuration Manager GUI

Ctmagcfg: Control-M Agent Konfigurasayonunu sağlar

Ctm_menu: Control-M Server konfigurasyonu sağlar.

Telnet: CLI remote desktop tool’udur. Firewall’ın bir potu bloklanıp bloklanmadığını anlamak için kullanılır.

Netstat: Bir makinada hangi portların dinlendiğini gösterir. Netstat  = net status’dan gelir.

Netstat -an|find /I “7006” : 7006 portunu dinleyen var mı?

Ag-diag-comm: Agent tarafında CLI üzerinden çalıştırılan utilitydir.  Agent’ın Server ile konuşmadığını kontrol eder.

Ctm-diag-comm: Server tarafında çalıştırılan utitltydir. Server’ın agent’la konuşup konuşmadığını kontrol eder.

Yukardaki ag ve ctm  diag comm’larda genel bir raporu ekrana gösterir.

Ctmagcfg: Agent tarafında konfigurasyon yapmamızı sağlar. Eğer bir server Agent’ın Authorized Server List’inde yoksa server Agent’a bağlanamaz. Ctmagcfg ile ilgili serever ilgili listeye eklenebilir.

Agdbglvl  Agent debug seviyesidir.

Agdbglvl 0: Debug seviyesini disable eder.

Agdbglvl 5: En yüksek seviyesidir.

KARIŞIK UTILITYLER

ctmgetcm: Control-M’e bir plugin yüklendikten sonra (Örneğin AFT.)  bunun EM tarafında refresh olması 24 saati bulabilir. Bu sebeple elle mühahele gerekir ve bu müdahele ctmget cm utilitysi ile yapılır. 3 parametresi bulunur.

• Host: Plugin kurduğumuz ajanın adı yazılır.
• AppType: * yazılır. Tüm uygulama tipleri dahil olur.
• Action: Get dersek refresh yapılmış olur. Amacımımız sadece görüntülemek ise view denilebilir.

Aşağıdaki gibi hazır batch kullanılabilir.

ctmgetcm -host agent_name -appltype “*” -action get

Windows EM kodu (Orbadmin ): İçerisinde pek çok komut barındırır. Örneğin orbadmin ns list ayakta olan naming Service/services listeler.

ctm_menu: Kontrol ve ayarların yapıldığı ana menü

ctmagcfg: Agent konfigürasyonu için bir menü açar.

ctmpsm: Kara ekran üzerinden (DOS/SHELL) jobları hold edip kill edebilmemizi sağlar.

Control-M’de log’datası toplama:

• Agent : ctma_data_collector –F ALL –days 2
• EM        : em_data_collector –F ALL –days 2 –> DB User/Pass ister
• Server  : ctms_data_collector –F ALL –days 2 –> DB User/Pass ister
• ctma_data_collector -F CMAFT -F AG -F ENV -F LOG_CFG -max_size 2048 -> max 2gb log oluşturur.

orbconfigure:Agent Connectivity  Firewall olan durumlarda Control-M EM’in en az 20 portluk bir aralığa ihtiyacı vardır. Bu utilty ile bu ayar yapılır.

The post Agent Connectivity ve Karışık Komutlar| Control-m #14 appeared first on Dinamik Network.

Raporlar dinamik olarak oluşturulan SQL sorgularının sonuçlarından elde edilmektedir. Program tarafında sonuçlar filtrelenmektedir. Bu sorgu sonuçları DB’deki bir kaç tablodan gelmektedir. Genellikle çoklu join ve union işlemlerinin sonuçları olmaktadır.

Çalışma Mantığı

1. Program tarafında filtreler kabul edilir ve SQL buna göre hazırlanır.
2. SQL çalıştırılır.
3. Rapor, SQL sonucuna göre hazırlanır.
4. Control-M Client GUI Application -> emreport.exe
5. Crystal Reports Report Designer Components -> RDC Crystal Reports CRViewer
6. Windows command Line/batch utility (emreportcli.exe)
7. Designed to create templates and generate reports
8. Reports can run interactively and in batch

Mimari

Raporlar EM DB üzerindeki talolardan elde edilir. Bu tablolar.

• Active and Arcgived Net Tables
• Job and Calender definitions Tables
• Forecast and Batch Impact Manager Tables
• Alerts and Audit & Security Tables
• Reporting and Measurements Tables

Raport Tipleri

General: Genel bilgileri raporlar. Örneğin alerts

Definations: Planning domaini ile ilgili bilgileri raporlar.

Active: Monitoring domaini ile ilgili bilgileri raporlar

Batch Impact Manager: BIM ile ilgili bilgileri raporlar.

Forecast: Forecast ile ilgili bilgileri raporlar.

Reporting Facility, yukarıdaki bazı rapor tipleri ( hepsi için değil ) için hazır templateler ile birlikte gelmektedir. Sensitive Report type dediğimizde kendi filtrelerimizi belirleyerek bir rapor oluşturabiliriz. Bu reporting facility’nin fonksiyonel bir yapısıdır. Bu template’lere bağlı olarak veya kendi belirlediğimiz kritelerle rapor oluşturabiliriz. Her rapor benzersizdir.

General Report’lar direkt olarak joblar’la ilgili değillerdir. Alert’lar, User autharization’larla ilgili olurlar. Defination Report’lar planing tarafında tanımlanmış Job’larla ilgili rapolardır. Örneğin Links Report çalıştırabiliriz. Bu bize Job’larımızın in ve out conditionlarını belirtir yada joliday weekdays calendar’ına göre tanımladığımız raporları listeleyen bir rapor oluşturabiliriz.

Active report ise active job DB’sinde bulunan Job’lar hakkında bilgi içerir. Job’un new day sonrası ne zaman order edildiği ya da genel olarak active Job’ların network’ü nasıl etkilediği gibi.

Bım reports ve forecast reports: bım ve forecast servisleri hakkında bize bilgi verir. Ayrıca JOB istatistikleri. Biriktirirler ve forecast tablolarına aktarırlar. Bu raporların yapılabilmeleri için Batch Impact Manager ve Forecast kurulu olması gerekir.

Bu iş Reporting Facility GUI üzerinden yapıılırken;

Raporlar oluşturulmadan önce -> Tools -> Database -> Verify Database Connection  demekte fayda vardır.

Rapor oluşturulabilmesi için EM DB erişilebilir durumda olmak zorundadır.

File -> New Ad-Hoc report diyerek template’ler il reportlarımızı oluşturabiliriz. Raporumuzu oluştururken template olarak da kaydedebiliriz.  Eğer aynı raporu oluşturmak istersek template’i seçip oluştururuz.

Bu iş Job olarak yapılırken;

Emrportcli path : CLI utilitymizin path’idir. Bu utility çalıştırılarak raport oluşturulacaktır.

Template name ve template name: Template ismini ve path’ini belirtiriz. Bu template kullanılarak rapor oluşturulacaktır. Bu Job’un scheduling parametreleri ile Job’umuzu otomatikleştirmiş oluruz. EM client 6.4.01 ve üzeri bir versiyon Windows1 makinaya kurulmalıdır. Windows makinanın DC ( Domain Controller) olması iyi olur.

Genel Özet

• Ad-Hoc Report bir kere çalıştırılır sonra silinir.
• Template, tekrarlı olarak oluşturacak olan raporlar için oluştururlur ve saklanır.
• Control-M Report Job, EM Client’larla aynı makinaya kurulmuş bir agent üzerinde çalışmak zorundadır. Ayrıca çalıştıracağı bir template olmak zorundadır.
• Control-M Report Job’un çalışması için emreportcli utility’sinin full path’i ve template’imizin full path’i gerekir.
• Control-M Utility Guide’da emreportcli hakkında bilgi bulunabilir.

emreportcli path: C:\Program files\BMC Software\Control-M EM 9.0.00\Default\bin32\emportcli.exe

Template Path: C:\Program Files\BMC Sofware\Control-M EM 9.0.00\Default\Data\Reporting\Templates

The post Reporting Facility | Control-M #13 appeared first on Dinamik Network.

TimeZone.dat dosyası bukonudaki ayar dosyası olup en önemli dosyadır. Bu dosya aynı zamanda DayLight Saving Time (DST) değerlerini de içerisinde barındırmaktadır. Job tanımlarında TimeZone belirtildiği zaman Job çalışma zamanı belitilen timezone’a göre olacaktır. Belirttiğimiz yerde saat kaçsa ona göre davranacaktır.

Bir Folder’ı otomatik çalışacak şekilde ayarladığımız zaman içerisindeki Job’lar kendi timezone’larına göre çalışacaktır. GD_FORWARD parametresi sayesinde (default dğeri WHY’dır.) klasör belirli bir timezone‘a göre schedule edildiği halde içerisindeki Job’lar kendi timezone’larına göre haraket edecektir.

Ctmudly utility’si kullanılarak bir Job’un farklı bir timezone’da çalışması sağlanabilir. Job’un çalışma parametreleri utility’e belirtilerek istenen zaman dilimde çalışması sağlanır.

TimeZone konusunda 3 adet çözüm uygulanabilir.

Sistem daily ile scheduling

• Tüm order işlemleri tek yerde ve tek zamanda yapılır.
• Tüm workload ortamı gözlemlenebilir.
• Aktif ortamın sıkışması ile sonuçlanabililr. Çok fazla bekleyen Job’tan dolayı performans olumsuz etkilenebilir. Job’ların çalıştırılabilimeleri için çok fazla zaman geçmesi gerekebilir.
• CTM Server sistem parametresi olan GD_FORWARD sistem parametresini Y olarak setin. Bu local zamanları bizden önde olanlar için kritiktir.
• Planning’te Order Metgod’u automatic olarak ayarlayın.
• Job tanımlarında uygun olan timezone’u ayarlayın.

User Daily ile pre-order etme

• System daily’den yük alır.
• Ortalıkta zamanını bekleyen Job’lar olmaz. ( wait-odat)
• Bir yerdeki timezone için tüm Job’lar ilgili timezone gün başlangıç ne zamansa o zaman başlar.
• User daily Job’lar gruplanabilir.
• Eğer Forward timezone scheduling gerekliyse autoedit’leme gerekir.

User Daily ile Order Etme

• System  daily’den yük alır.
• Ortalıkta zamanını bekleyen Job’lar olmaz ( wait_odat)
• Job’lar sadece aktif olduklarında active environmentta görünürler.
• Autoedit’lere gerek yok.
• User daily Job’lar tüm saatlerde çalışabilirler.
• Bir problem olduğunda timezone’larla boğuşmak gerekebilir.
• TimeZone’ların çok kullandığı yapılarda iyi bir seçenektir.

TimeZone’lar Hakkında İpuçları, Önceriler ve Hatırlatmalar

• GD_FORWARD parametresi Y olarak set edildiğinde Job’lar system’in New Day’in de order edilir. Y parametresi defaulttur.
• Eğer TZ’ların order edilmesi için SYSTEM daily kullanılıyorsa,  değişikliklerimizi erken yapmamız gerekir.
• TZ içeren Job’ların ekstra iki durumu olabilir. WAIT_ODAT, POST_ODAT
• TZ içeren Job’lar eğer New Day geldiğinde hala wait scheduling durumundaysa silinmezler.
• Mini New Day her 30 saniyede bir timezone içeren Job’ların durumunu ayarlar.
• Control-M günleri, Control-M Server’ın Local’ine veya dengelemesine bakılmaksızın er zaman aynı saatte başlar.
• TimeZone.dat dosyasında değişiklilk yapılırsa Control-M Server’ı resttart etmek gerekir.
• Timezone.dat dosyası EM ve Control-M Server’larda ve her bir EM client’ta bulunur. Bu dosyanın manuel olarak dağıtımı gerekir.
• EM üzerindeki TimeZone.dat dosyasının değişimi componentlerin restart edilmesini gerektirmez.

The post Timezone Hakkında Herşey | Control-M #12 appeared first on Dinamik Network.

Filewatcher Nedir?

Bir dosyanın oluşmasını yada silinmesini monitör eden control-m utility’sine FileWatcher denir. Bir dosya oluştuğunda dosyanıp büyüyüp büyümediğini ve boyutunun sabit mi kaldığını kontrol eder. Eğer Control-M bir procces’i direkt olarak monitor edemioyrsa, FileWatcher ile dolaylı yoldan bir proccess’i monitör edebiliriz.

Örneğin: Bir payroll JOB’unu direkt olarak monitör edemeyebiliriz. Ancak job, file system’e bir file koyabilir.  Böylece biz o file’ın durumuna göre başka bir JOB triger edebiliriz.

File Watcher bir Control-M Agent utility’sidir. Agent üzerinde çalışır. Control-M  AFT’nin de bir FileWatcher’ı mevcuttur. AFT FileWatcher’ı bu FileWatcher’a benzer şekilde çalışır. FTP yada SSH protokolünü kullanarak Remote File System üzerindendeki dosya yada dosyaları monitor eder.

FileWatcher Local File System’deki ya da ilgili network’deki paylaşıma açık dosyaları kontrol edebilir.

FileWatcher Job çalıştırmanın bir kaç yolu vardır;

Job Form

Job’un ilgili parametreleri girilerek JOB ordelir. En mühim parametreleri aşağıdadır;

• Wilcard is user : Default olarak N seçilidir. Eğer JOB sonucu birden fazla dosya bekleniyorsa Y seçilebilir. Eğer * kullanılırsa ilk eşleştiği dosyayı kontrol ederek devam edecektir.
• FileMode: CREATE yada DELETE olabilir. Eğer DELETE seçili ise ilk önce dosya var olmalıdır. Eğer CREATE seçili ise dosya daha önceden oluşturulmamış olmalıdır.
• Min Detected Size: 0 byte üzeri bir değer verirsek daha gerçekçi bir arama olacaktır.

CLI Utility

-CLI Komutu : ctmfw C:\payroll\payroll.txt CREATE 4 5 2 3 N NOW 0 NO_MIN_AGE NO_MAX_AGE

Input File Kullanarak

• Windows Service config file path : <Agent_Home>/data/ctmfw.cfg
• Input dosyaları hem Unix’te hem de Windows’ta kullanabilir.
• Ctmfw -input full_file_path_filename
• İnput dosyasındaki ilk ayarlamalar tüm filewatcher job’ları için globaldir. Tüm filewatcher Job’ları oradaki değere göre işlerini yapacaklardır. Her bloktra tek bir file için yapılmaktadır. THEN kısmında durum başarılı ise yapılacaklar, ELSE kısmında durum başarısız ise yapılacaklar bulunur.
• CLI üzerinden FileWatcher çalıştırdığımızda FileWatcher’ın ne zaman çalıştığı ve nasıl çalıştığı hakkında bilgi edinemeyiz. Monitor edemeyiz. Ancak tek input dsoyası ile birden fazla FİleWatcher Job ayarlayabiliriz.

Bu Job tipini kullanınrken ilgili User’ın file üzerindeki yetkileri olmalıdır. ( Dosya Silme, Dosya oluşturma) Agent debug edildiğinde ctmfw dosyaları oluşacaktır. Bu dosyalar bize gerekli bilgileri gösterecektir.

Re-run Codes: 0 = 0 Success, 1=Fail 7=Sistem dosyası belirtilen süre içerinde bulunamadı.

The post FileWatcher Hakkında Herşey | Control-M #11 appeared first on Dinamik Network.

Agent Upgrade With NoDownTime

Özellikle 7/24 çalışan sistemlerde müşteriler Control-M  EM ve Control-M Server sistemlerini güncel tutmak isteseler dahi bunu yapacak zaman bulamamaktadırlar. Sistem kurulu olup FIXPACK’leri olmayabilmekte veya sistem versiyonu eski kalabilmektedir.

Remote Hosts yapısının çıkma sebebi upgrade işleminin daha kısa sürede yapılabilmesi sağlamaktır ve kontrol edilmesi gereken agent sayısını azaltmaktır. Yine de bu şartlar altında agentların upgrade işlemleri için bir zaman çizelgesi oluşturulmak zorundayız.

Bu işin Faydaları ;

• Production tarafında zayiat çıkmasını engeller. ( Sistem kapatılmak zorunda kalmaz)
• Çalışan Job’lar etkilenmez.
• Business kısmı için şeffaf bir işlemdir.
• Güncel sürümlerde kalmak kolaylaşır.
• Acil kurumlar için onay almak daha kolay olur ( sistem kapanmayacağından)
• Güncel kurulum prosedürünün değiştirilmesine gerek yoktur .

Gereklilikler;

• Unix üzerinde çalışan Agent’lar hemen upgrade edilebilir.
• Windows Agent’lar için Control-M Server versiyon 8 FIXPACK 3 ve üzeri kurulu olmalıdır.
• Control-M Server versiyon 8 ve üzeri olmalıdır.
• Control-M Agent versiyono 6.4.01 ve üzeri olmalıdır.

Kurulum Sırasında Yapılan İşlemler;

1. Control-M Server’ın versiyon 8 ve üzeri olup olmadığı kontrol edilir.
2. Kurulum dosyalarını temp folderına çıkartılır.
3. Agent’ın güncel versiyonunun Back-Up’ını alır.
4. Yeni versiyonun dosyalarını Agent’ın klasörüne kopyalar.
5. Exe_800 klasörü altına yeni Agent Binary’lerini kurar.
6. Control-M Server’a upgrade’in başladığını bildirir.
7. Eski Agent’ın Listener ve Tracker processlerini kapatır.
8. Güncel exe folder’ını exe_old olarak adlandırır.
9. Exe_800 folder’ı içerisine exe isimli sembolik bir link oluşturur.
10. Agent konfigürasyon değişiklikleriniyapar (os.dat, config.dat)
11. Tüm çalışan jobları listeleyen bir dosya oluşturur.
12. Yeni versiyon Listener ve Tracker processlerini başlatır.
13. Control-M Server’ı upgrade’ın bittiği konusunda bilgilendirir.
14. New-Day Process ile exe_old gibi gereksiz dosyalar temizlenir.
15. Setup.sh çalıştırıldığında Upgrade seçeneği olacaktır.
16. Bu işler Server tarafında CE process sayesinde takip edilir

LDAP İntegraiton

Control-M OpenLDAP platform tabanlı LDAP uygulamalarına entegre olabilir. Bu konudaki popüler yapılar Active Directory(AD), SunOne(Oracle), Directory Server (iPlanet)’dir.

Versiyon 6.2 : API ile LDAP entegrasyonu tanımlanır.

Versiyon 6.3 ve 6.4 : User Level Mapping

Versiyon 7.0 ve 8.0 : Group Level Mapping

LDAP Grupları Control-M Gruplarına Map edilebilir.  Production Control Group’unun Administrative işler yapması isteniyorsa Admin Group’a map edilmelidir. Batch Services Group’un kendisi ile ilgili servisleri monitor etmesi isteniyorsa Browse Group’a map edilmelidir.

LDAP Authentication Process

1. Control-M GUI’den credantial girilir.
2. GUI Server Credantial bilgilerini EM Servers iletir.
3. EM Server Credential bilgilerini LDAP Server’a iletir.
4. LDAP Server tarafında Credential kontrol edilir.
5. Eğer crendial geçerli ise Credential User’ının grubunun yetkisi kontrol edilir.
6. Her şey tamamsa LDAP Server’a authentication sağlanır.

CCM üzerinde System Parameters’tan LDAP kısmına gelinir. Enable LDAP Authentication kutucuğu seçilir. User’lar arasılarında kullanılarak girilir. Transmissions Protocol TCP ya da SSL olabilir. LDAP Directory Server Type Active Directory ya da Planet olabilir. Bağlantı bilgileri bertilip değişiklikler başarıyla activate edildikten sonra;

Workload Automation üzerinden Autgorizations -> Groups -> LDAP Groups — kısmına LDAP grubumuzun adını ekleyerek grubu map etme işlemini tamamlarız.

LDAP tarafında dikkat edilmesi gerekenler;

• LDAP Server’ın adı ve portu.
• User’ın LDAP server’a connect olabilmesi ve ilgili directoryde arama yapabilmesi
• Arama merkezi

The post LDAP İntegraiton ve Agent Upgrade | Control-M #10 appeared first on Dinamik Network.

Users & Groups

Genelde yekilendirmeler yapılırken groupları yetkilendirmek administrative açıdan daha kolay olmakta ve yönetimi basitleştirmektedir. Gruplara atanan yetkiler eğer Default olarak işaretli ise gruba bağlı userlar da bu yetkileri INHERIT edecektir.

LDAP userları LDAP Group Mapping yapısında INHERITANCE alırlar. Yukarıdaki DEFAULT kuralı burada da geçerlidir. LDAP tarafından Local Admin Account’unu bilmemizde yarar vardır. Eğer esas kullandığımız hesapta bir problem olursa Local Admin Account’u ile giriş yapacağız.

Authorizations Bölümleri ve Amaçları

General: Username, Password, Password Policy ayarları yapılır.

Member Of: User’ların üye olacağı gruplar belirenir. User, hakları group/grouplardan INHERIT (kalıtım) edecektir.

Active: Monitoring tarafında user’ın/group’un yetkileri ayarlanır. (ViewPoint yetkilendirmesi)

Privileges: User’ın/Group’un EM’nin hangi özelliklerine erişebileceği ayarlanır.

Eğer group söz konusu ise DEFAULT seçili olanlar group’a bağlı user’ların INHERIT edeceği haklardır.

Global Conditions : Global Condition’ların PREFIX’lerinin değiştirildiği erkrandır. Genelde sadece admine bu yetki verilir. Buradaki bir değişiklik tüm Control-M sistemini etkileyecektir.

Calendars : BROWSE ve UPDATE yetkisi verilebilir. Yetkilendirmenin group bazında yapılması önerilir.

Folders : BROWSE ve UPDATE yetkisi verilebilir. Yetkilendirmenin group bazında yapılması önerilir.

Run As Users: Kimlerin JOB oluşturup çalıştırabileceğini ayarladığımız kısımdır. Hem Planinnig hemde Monitoring tarafını etkiler.

Workload Policies : Normal user’ların yetkilendirmelerinin y apıldığı kısım.

Services: BIM ve Self-Service yetkilendirmelerinin yapıldığı yerdir. Servis için yaptığımız yetkilendirmeler servis içerisindeki jobları KAPSAMAZ! Onlar için ayrıca yetkilendirme gerekecektir. Çünkü JOB’lar ( aktif olanlar ) zaten monitoring ekranındadır. BIM ya da Self-Service job’ları ayrıca Web Browser’da görüntüleriz. Yaptığımız yetkilendirmeler orada yansıyacaktır. Active Authorizationla bu yetkilendirme ayrı şeylerdir.

Prerequisite Conditions : Monitoring tarafındaki conditionlar ile ilgili yetkilendirmelerdir.

Control Resources : Monitoring tarafında kaynakların yetkilendirmesi yapılır.

Quantitative Resources : Monitoring tarafında kaynakların yetkilendirmesi yapılır.

LDAP Groups : Bir LDAP grubunu bir EM Authorization grubuna map ettiğimiz yerdir.  Eklerken Domain Name yada Short name yazabiliriz. Domain name yazılması önerilir. LDAP grubuna göre bir user ile Login olunduğunda ilgili LDAP grubunun ne hakkı varsa onlara sahip olacak.

Twists & Tips

Folder Security söz konusu olduğunda 4 adet erişim level’ı vardır. NONE, BROWSE, UPDATE, FULL. Bu parametre bir folder’ın schedule edilebilmesi ya da folder içerisindeki Job’un order edilebilmesi için user’ın ya da group’un sahip olması gereken yetkiyi belirtir.

Default olarak bu parametre UPDATE_ACCESS diğerine sahiptir. Yani user’ların bir folder’ı schedule edilebilmesi için UPDATE yetkisi olması gerekmektedir. Ancak user yada group sadece JOB’u order edecekse UPDATE yetkisine gerek yoktur. Bu yüzden bu parametreyi BROWSE_ACCESS olarak değiştirersek user’ların sadece BROWSE yetkisi olması gerekir. Aksi takdirde Folde’ı order edemeyeceklerdir.

EnableRemoteBrowsing: Default olarak Yes durumdadır. Bu durumda user’ları Agent’ın Local File System’ini götüleyebilecek, dosya listelerini çekebileceklerdir. Bunu disable edersek bunları yapamayacaklardır.

PGUI & KICK: EM üzerimde bir değişiklik yaptığımızda değişiklerin yansıması için ilgili user’ın logout & login olmaları gerekir. Eğer ilgili user’larla direkt iletişimimiz yoksa onu sistemden logout yaptırabilir.  Onu yeniden login olma zorunda bırakabiliriz. Bunun için EM’de ControlShell açarız. PGUI ile ilgili user’ı bulur, KICK ile onu sistemden dışarı atarız.

EM_BYPASS_CTMSEC: Control-M Server parametresidir. Control-M Server tarafından güvenlik kriterlerini görmezden gelir, sadece EM Authorizations göre haraket eder.

Authorization Flow 

Workload Automation GUI -> GUI Server -> Gateway -> Control-M Server -> Control-M Agent

Authorization’lar Agent, Server, GUI Server ve EM seviyelerinde sağlanır.

Agent Tarafında

Unix sistemlerde Job’lar RunAsUser’da kim varsa o user’ın yetkileriyle çalışır. Windows’ta ise eğer LogonAsUser seçeneği seçili ise o User’ın yetkileri ile çalışır. Eğer seçili değilse agent servisinin default User’ı ile yeni local system account’un yetkileri ile çalışır.

The post Authorizations | Control-M #9 appeared first on Dinamik Network.

Client Distribution

Client Distribution aracı ile tek bir noktadan pek çok noktaya client kurulumu, fix-pack kurulumu ve patch kurulumu yapabiliriz. Bunu desteklenen tüm makinalarda yapabiliriz. Ayrıca tüm userların son updateleri almalarını sağlar. Böylece user en son update’i kurmadan programı çalıştıramaz.

İşlem yapacak dosyaları EPD’den indirerek EM’nin Local Repository’sine indirmemiz gerekir.

• Linux: $EM_HOME/Client_Updates/9.0.00
• Windows : Program Files/ BMC Software / Control-M WM /9.0.00/Default /Client_Updates/9.0.00
• Web Server’ın ayakta ve çalışıyor olması gerekmektedir. Aksi takdirde deployment yapılamayacaktır.

Web Launch ile kıyaslandığında;

• .Net Deployment kullanmaz.
• Package’lerin elle manuel olarak build edilmesine gerek yoktur.
• Unix’ten yada Windows’tan çalıştırılabilir.
• Kalan Update’ler üzerinde kontrol sağlar.
• Aynı EM Server üzerinden 32 yada 64 bit deployment yapılabilir.

Client Disturbution’ı açtığımız zaman önümüze bir URL gelecektir. Bu URL user’ların installtion’lara ulaşabilecekleri URL’dir. Eğer Web Server ayakta değilse ya da çalışmıyorsa userlar URL’e bağlanamayacaktır.  Userlar URL’e bağlandıklarında makinalarının 32/64 bit olduğu kontrol edilir ve doğru installer user’a sunulur. Kurulum yapılabilmesi için Control-M EM server’a olan bağlantı bilgileri Installation Wizard tarafından otomatik alınır.

Kurulum bittiğinde Control-M Workload Automation Client user’ların level’lerine göre erişilebilir olacaktır.

Bu tool ile client update’lerinin otomatik olarak yapılmasını sağlayabiliriz. Ya da belirli bir günde updatelerin kurulumunu sağlayabiliriz. Eğer bu iş End User’a kalırsa ve End User update’i kurmazsa login olmasını engelleyecek şekilde bunu ayarlayabiliriz. Böylece End User update’i kurmadan sisteme login olmayacaktır.

Ayrıca Client kurulumunda .Net Framework 4.5.1 ve üzeri kurulmuş olmalıdır. Client Distribution ileyeni versiyonlar, pacth’ler, fix pack’ler ve SSL sertifikalarının kurulumunu yapabiliriz. Paketler HTTP/HTTPS üzerinden transfer edilebilir. EM Patch’lerinin deploy edilmesi konusunda Article Solution 000102790 faydalı olacaktır. Client updateleri sadece bu tool ile yapılmış kurumlarda uygulayabilir.

High Availability

Prod ortamının ayakta kalma süresini maksimize eden ve kesinti olduğunda veri kaybını engelleyen sistemdir.

Çalışma mantığı şu şekildedir;

• Primary serverdaki Configuration Agent Process ( CA ) , Secondary Server’daki Configuration Agent Process’e Confirm etmesi için LifeCheck gönderir.
• Secondary Server’daki CA, Life Check ( Confrim ederek ayakta ve erişilebilir durumda olduğunu Primary Serverdaki CA’ya bildirir.
• Her 2 CA da DB’yi her 15’sinde 1 UPDATE ederler.
• Yazma işlemi, Oracle DB ayarlarına göre değişir. Primary Server’daki CA, DB’ye timestamp de yazar.
• Secondary Server’ın durumu Oracle mimarisindeki yöntemle kontrol edilir.
• Her iki hostta da DB bulunur. Replication işlemi uygulanmış data Shared Driverda saklanır. Her iki DB de replike edilmiş detayı ( Shared Drivedaki detayı ) kullanırlar.

Bu yapıyı elde etmek için iki adet Control-M Server olmalıdır. İkinci Control-M Server’ın kurulumu için “Additional Installations”tan “Secondary Installation For High Availability” seçneği seçilir. DB seçeneklerimiz sadece Oracle ve Postgre SQL şeklinde gelir. Secondary Server’da ilgili portların mutlaka açık olması gerekir. Aksi halde kurulumuş fail olur.

Kurulum tamamlandığında CCM üzerinden FailOver serverımızı görebiliriz. DB Replication özelliği sadece Postgre SQL olduğunda aktif oluyor. CCM üzerinden konfigürasyon ayarlamaları yapılabilir. FailOver Mod seçilebilir.

• Config.dat dosyasına bakarak Control-M ile iligili tüm parametreleri görebiliriz.
• Local_config.dat dosyasına bakılarak High Availability’nin aktif edilip edilmediğini görebiliriz.

Failover Seneryoları

Failover senaryoları iki çeşittir.  Manuel ve Automatic. FailOver’ın çalışabilmesi için her iki makinada da CA Processin ayakta olması ve çalışıyor olması gerekmektedir.

FailOver çalıştıktan sonra secondary malina primary makina olarak atanabilir ya da primary makinaya fallback yapılabilir. FailOver senaryosu Automatic olarak seçildiğinde FailOver işleminin otomatik olarak yapılması için aşağıdaki üç maddenin gerçekleşmesi gerekir.

• Primary Configuration Agent down olduysa ( DB’ye timestamp eklenmez )
• Primary Control-M Server down olduysa ( DB’ye yeni timestamp eklenmez)
• Primary Control-M Server Desired State Up ise

5 kere Primary Server’a erişilmeye çalışacaktır. Erişilemezse FailOver işlemi başlayacaktır. Eğer Primary Server down olmuşsa ve Secondary Server çalışıyorsa istenildiği zaman manual FailOver yapılabilir.

• FIXPACK1 ile High Availability aşağıdaki gibi DISABLE/ENABLE edilebilir.
• Ctmha -ACTION UPDATE_HA_MODE DISABLED
• Ctmha -ACTION UPDATE_HA_MODE AUTO

Böylece High Availability daha fonksiyonel şekilde kullanılabilir.

Bir failure durumunda CA loglarını toplamamız gerekir. Ancak CA Debug’ı aktif etmemeliyiz.  Aksi takdirde High Availability’nin temel bilgileri silinecektir.

Sadece Configuration Agent’ın debug’ını aktif etmeliyiz.

• Shctm komutuyla Control-M Server üzerindeki tüm processleri görebiliriz.
• Show_ca : Configuration Agent Processini gösterir.

Bu şekilde High Availability sağlanarak, server’lar arasında geçişler gerçekleştirilir.

The post Client Distribution & High Availability | Control-m #8 appeared first on Dinamik Network.

Control-M Üzerinde Agent Depoloyment 

Agent Deployment ile agent upgrade işlemlerini otomatik olarak yaptırabiliriz. Tek noktadan ve belirli bir pathden (EM Server üzerinde) dosyalarımızı ilgili serverlara ve agentlara kopyalar ve upgrade işlemi yapabiliriz. Eğer istersek downgrade işlemi de yapabiliriz. Bu gibi işlemler çok büyük yapıdaki kurumlar için bulunmaz bir nimettir. Çünkü her agent üzerine dosya transferi ve tek tek kurulum yapma işleminden kullanıcı kurtulmuş olur.

CCM üzerinden Manage sekmesine tıklanır ve Deployment butonuna basılarak Deployment ekranına ulaşılabilir. Bu aracın kullandığı 4 adet sistem parametresi mevcuttur.Bunlar;

• Local Repository Location
• Central Deploy Location
• AD_GA_RETAIN_DAYS,
• AD_RETAIN_PACKAGES.

İki türlü activity düzenlenir. Bunlardan biri sadece dosyların upgrade yapılcak yerine taşınmasını kapsarken diğer ise taşıyıp upgrade işlemini gerçekleştirmesini sağlar. Bu seçenekler;

• Tranfer Activity
• Transfer and Automatically and İnstall Package

Dosya yerine göre ise yine iki parametre mevcuttur. Local Repository Location ve EM server üzerindeki default kayıt yeridir.

Burada bu aşağıki şekilde bir path bulunmuyorsa kendi elimiz ile oluşturmamız gerekir.

Linux için;  $EM_HOME/AUTO_DEPLOY -> Control-M EM Server üzerinde

Windows için; C:\Program Files\BMC Software\Control-M EM 9.0.00\Default\AUTO_DEPLOY şeklindedir.

Bu path EM Serverın Local Repositorysidir. Eğer CentralDeployLocation belirtmemişsek Agent Deployment için gerekli dosyalar buradan alınarak ilgili yerlere kopyalanacaktır.

CentralDeployLocation: Bir Kayıt ve Upgrade Merkezi gibi düşünülen EM server harici kayıt ve depolama yeridir. Upgrade dosyaları burada depolanır.

Eğer bu parametre tanımlanırsa dosyalarımızı bulunduğumuz network lokasyonu içerisinde istediğimiz yere koyabiliriz. EM Userının bu lokasyona erişim problemi olmadığı sürece bir problem olmaz. Deployment yapılırken dosyalar burada belirtilen pathden alınır.

Deployment İşlemi

DEPLOYMENT_THREADS: EM üzerindeki bir sistem parametresidir. Birden fazla agentı aynı anda deployment yapabilmemizi sağlar. Default değeri beştir. İhtiyaca göre bu değer artırılabilir ya da azaltılabilir.
AD_GA_RETAIN_DAYS: Upgrade işlemi yapılırken Server’ın güncel versiyonunun bir BACK-UP’ı alınır. Bu BACK-UP dosyalarının kaç gün saklanacağını belirten parametredir. Default 30 gündür. İhtiyaca göre değer değiştirilebilir.
Bu BACK-UP alındığı için upgrade sonrasında eğer istenirse downgrade işlemi de yapılabilir. Ancak bir server ya da agentı direkt olarak downgrade yapamayız.
AD_RETAIN_PACKAGES: Upgrade yapılmadan önce dosyalar ilgili yerlere gönderilir. Bu dosyaların (kurulum dosyaları) ne kadar süre ile ilgili yerlerde tutulacağını belirten parametredir. Default 30 gündür. İhtiyaca göre değer değiştirilebilir.

Not: Agent versiyonlarının 7.0 ve üzeri olması zorunludur. İşlemin yapılması için öncelikle kurulum dosyaları indirilmelidir.

Agent dosyaları Windows ve Linux için. Başka sistemler için de seçenekler mevcuttur.

Server ise yukarıdaki gibidir.

Dosyaları EM Server üzerinde Local Repositorye ya da CentralDeployLocationa koyarız.

NOT: Linux ve Unix için paketler indirildiklerinde uzantıları küçük harfe dönebilmektedir. Agent Deployment Tool Case-Sensitive (büyük-küçük harf farkeder) bir yapıya sahiptir. Bu sebeple eğer uzantı küçük harf olursa Agent Deployment Tool dosyaları algılamayabilir. Bu sebeple uzantıyı büyük harf yapıp yeniden denemeliyiz. Sonrasında Agent Deployment Tool üzerinde dosyalar görünecektir.

Daha sonrasında menüden aşağıdaki gibi yaparız.

Dosyalarımız hazır ise değer işlemler otomatik hallolacaktır. Öncelikle dosyalar kopyalanacak sonrasında güncel sürümün BACK-UP dosyaları oluşturulacak (downgrade işleminin available olması için) sonrasında kurulum dosyaları çalıştırılarak upgrade işlemi gerçekleştirilecektir. Upgrade yapılıdığında agentın ya da serverın denemesi otomatik olarak deployment tool tarafından yapılmaktadır.

The post Agent Deployment | Control-m #7 appeared first on Dinamik Network.

Advanced File Transfer

EM: Job’un durumunu gösterir.

Server: Job’u schedule eder.

Agent: Job’u çalıştırır.

AFT: Agent’a kurulu bir plugin’dir. FTP sunucular ile iletişim kurmayı ve dosya alışverişini sağlar.  Bu işi iki FTP server arasında yada Local Makinanın uzaktaki bir Makina yada FTP serever arasında olabilir.

AFT, FTP Client fonksiyonlarını içerisinde barındırır. Local dosya sisteminde dosya okuma ve yazma işlemini handle edebilir. AFT’nin çalışabilmesi için FTP accountlar tanımlanmış olmalıdır. FTP joblar çalışırken account infoyu kullnacaktır.

• AFT ayarlanırken hangi Control-M user/user kullanacağı belirlenir. Buna Conneciton Profile denir.
• PGP kullanılarak dosyaların şifreli olarak transfer edilmesi sağlanabilir.

Batch Impact Manager (BIM)

Kritik iş akışlarını izlememize olanak veren Add-on’dur. Yüzlerce Job’u monitor etmek yerine onları tek bir servis olarak monitor etmemize olanak verir. BIM olmadan JOB’larımızın ne kadar süreceğini, gecikmeleri kendimiz hesaplamak zorunda kalırız. BIM ile bu hesaplar otomatik yapılır.

BIM Job’ları tanımlamadan önce en kritik olan job yada joblarımızı iyi seçmemiz gerekir. Diğer Job tipleri gibi BIM joblarıyla da notification’lar yapılabilir. BIM joblarında belirli varsayımlar bulunur.

1. External Conditions: Bir Job’un çalışması için dışarıda (Job’un harici diğer JOB ya da servislerde) oluşması gereken durumlardır. BIM default olarak bu conditionların oluştuğunu varsaymaktadır. Bu yüzden bir JOB BIM’e göre ortalama zamanda çalışacaktır.
2. Confrim Jobs: Servis içerisinde confirm bekleyen JOB’lar olabilir. BIM’e göre default olarak confrim bekleyen JOB’lar confrim edilmemiştir. Bu yüzden Job’larımızı buna göre ayarlamalıyız.
3. Not OK Jobs: Bir Job’un Not OK olması tüm serviste bir sıkıntı olduğu anlamına gelmez. Sadece ilgili JOB için en geç çalışma zamanına erişilmiş demektir ve bu durumda bir alert gönderilebilir. BIM’e göre default olarak Not OK biten Job’lar bittikleri anda Rerun edilir.
4. Jobs With No Statistics: Eğer bir JOB servise yeni konmuşsa (ilk defa çalışacaksa) bir istatistiği olmayacaktır. Bu durumda;

Avarage Run Time: 5 dk

Avarage Start Time : New Day Time

Olarak varsayılır. Bu durum potansiyel servisi etkileyebilir.

BIM için lisanslama gerekmektedir. EPD’den indirilir. EM hosta kurulur. Orada konfigürasyonu yapılır. Sonra Job tanımlanır.

• Eğer ortamda Birden fazla GUI Server varsa BIM Server’a GUI Server’lardan Birini göstermemiz gerekir.

BIM Server GUI  Server’a bağlanarak ViewPoint’deki tüm jobları alır. BIM Server ile tüm Control-M Serverlardaki tüm BIM joblarını görebiliriz. Eğer Webserver kuruluysa servisleri web üzerinden görebiliriz. Default portu 18080’dir. Eğer EM Client kurulu değilse servisleri görmek için kullanılır. Kullanımı için bir web user gerekir.

BIM Server’ı email yoluyla aler göndermek için kullanmak istersek System Parameters’dan EmailSender ve EmailServer parametrelerini ayalamamız gerekir. BIM dakikada bir servisin çalışmasını hesaplar. Service Assumptions kısmından servisin durumu, ne kadar süreceği, görüntülenebilir. BIM Server, hesaplamalarını kendi default ayarlarına göre yapacaktır.

Eğer istersek rule tanımlayabiliriz. Böylelikle BIM Server hesaplamalarını yaparken rule/rulelarımızı da hesaba katarak gerçekçi bir hesap ortaya koyar. Service Report’dan da farklı bir görünüm ile servisimizi gözlemleyebiliriz.

BIM Report Görünümleri

Critical Path: Servis içerisinde çalışması gereken Job’ların en kısa ne kadar sürede çalışabileceğini ortaya koyar. Böylece servisin çalışıp çalışamayacağını, çalışmayacaksa ne kadar gecikeceğini görmüş olruz. Job’ların servisin çalışma zamanını ne kadar etkileyeceklerini görmüş oluruz.

Filter Critical Path: Job’ları ViewPoint üzerinde yeniden konumlar. Böylece en kritik Job’ları daha rahat görürüz.

BIM bir real-time servis değildir. Ne kadar çok Job eklenirse o kadar çok hesaplama yapacak demektir. Ayrıca gecikmeleri hesaplayamaz. Hesaplama işleminin bittiği vakit, servisin çalışmasının tamamıyla bittiği vakittir.

Critical Path, aralarında en kısa zaman boşluğunun olduğu joblardan oluşan Path’dir.

Update Deadline : Eğer bir bildiğimiz varsa servisin bitiiş zamanını elle belirleyebiliriz.

Eğer EM Client kurulu değilse Web Server’dan yada Self Service üzerinden BIM joblarımızı görüntüleyebiliriz.

AFT ve BIM konusunda notlarımız bu kadar. Bir sonraki Control-M yazısında görüşmek üzere. Diğer Control-M yazılarımız için tıklayabilirsiniz.

The post AFT ve BIM | Control-M #6 appeared first on Dinamik Network.