Merhaba,
Hepimizin fark ve takip ettiği gibi artık sistemler arası otomasyon gün geçtikçe önem kazanmakta. Özellikle Microsoft Azure kullanımında arka planda çalışan otomasyon işlemlerinin ne kadar yoğun olduğunu tahmin etmek zor olmayacaktır. Bu makalemde sizlere System Center ürün ailesinin bir bileşeni olan Orchestrator ın nasıl çalıştığı ve bileşenleri hakkında genel bilgi vermeye çalışacağım. Bu makale ile birlikte aslında otomasyon dünyasında beraber bir yolculuğa çıkıyor olacağız.
IT dünyasında otomasyonun yani bazı işlemlerin bizim önceden tasarladığımız şekilde ilerleyerek işlemleri tamamlaması gittikçe önem kazanmakta. En basiti günlük olarak yaptığımız işlemleri (bir sunucu üzerinde ki hizmetin çalışıp çalışmadığı, kullanıcı parolasının sıfırlanması ve parolanın kullanıcının cep telefonuna gönderilmesi vb.) ya da çok daha kompleks işlemleri arka planda bizim için yapıyor olması bile sistem yöneticilerinin yükünün hafiflemesi anlamında önemlidir. Aynı zamanda System Center ailesinin diğer bir ürünü olan Service Manager ile de bağlantı kurabilir ve son kullanıcılara açılan bir portal üzerinden yapılacak işlemlerin otomasyonunda da Orchestrator arka planda kullanılabilmektedir.
Orchestrator ın bileşenlerine bakacak olursak,
- Runbook
- Management Server
- Runbook Server
- Orchestrator Database
- Runbook Designer
- Runbook Tester
- Orchestration Console
- Orchestrator Web Service
- Deployment Manager
şeklinde sıralayabiliriz. Bu bileşenleri açıklayarak makalemize devam edelim.
Runbook: Runbook dediğimiz aslında yapmak istediğimiz iş akışının görsel olarak tanımlanmasıdır. Runbook Designer kullanarak bu runbook ları görsel ortamda oluşturabilir, runbook içerisinde ki bileşenlerin birbirleri ile ilişkisini tanımlayıp akış diyagramını oluşturarak yapmak istediğimizi ortama yansıtabiliriz. Örneğin ortamda bulunan sanal makineler üzerinde bulunan snapshot sayılarını tespit edip bunlar arasında sayısı birden fazla olanlar için diğer bir system center bileşeni olan Operations Manager üzerinde alert oluşturabiliriz. Ya da sunucularımız üzerinde sürekli çalışıp çalışmadığını kontrol etmemiz gereken bir hizmetin çalışma ya da çalışmama durumları için farklı davranışlar tanımlayıp bunların uygulanmasını sağlayabiliriz. Tüm bunları tasarladığımız ve uyguladığımız ortama Runbook denir. Runbook lar herhangi bir yüksek erişilebilirlik çözümü sunmamaktadır. Onun yerine runbook ları çalıştıran Runbook Server ın yüksek erişilebilirlik çözümünün uygulanması yeterli olacaktır.
Management Server: Management server Runbook Designer ile tüm verilerin bulunduğu Orchestrator veritabanı arasında iletişimi sağlayan bir katman olarak düşünülebilir. Her orchestrator ortamında sadece bir Management Server olabilir. Ancak runbook ların çalışmaya devam etmesi için Management Server ın çalışır durumda olması gerekmemektedir. Eğer Management Server ayakta değilse Runbook Designer tarafında çalışma yapılamayacaktır ancak o anda çalışan runbook lar çalışmaya devam edeceklerdir. Dolayısıyla var olan runbook ların da çalıştırılması, durdurulması ya da izlenmesi gibi işlemler yapılamayacaktır.
Runbook Server: Runbook Server Orchestrator Deployment Manager ile yapılandırılan bir Windows hizmetidir. Runbook Server, Management Server a ihtiyaç duymadan direk olarak orchestrator veritabanı ile konuşmaktadır. Ortamda birden fazla Runbook Server bulunabilir, böylece çalışan runbook ların oluşturduğu yoğunluk dağıtılabilecektir ve aynı zamanda yüksek erişilebilirlik de sağlanabilmektedir. Bir Runbook Server üzerinde aynı anda en fazla 50 Runbook çalıştırılması önerilmektedir. Genel dizayn olarak Runbook Server lar yüksek erişilebilirlik yapılarını (failover cluster) desteklememektedirler. Yedeklilik için iki farklı çözüm düşünülebilir. Bunlardan ilki az önce bahsedildiği gibi birden fazla runbook u ortamda bulundurup çalıştırılan runbook ları dağıtarak yedeklilik sağlanabilir. Diğer yöntem ise, heartbeat yöntemi kullanılarak 3 kayıp heartbeat sinyali ya da 45 saniye diğer runbook server a ulaşılamaması durumunda ilgili runbook server üzerinde çalışan runbook lar diğer runbook server üzerine aktarılabilir. Bu işlemi yapabilmek için “Runbook Server Monitor” hizmeti kullanılabilir. Bu hizmet Orchestrator Runbook Server ların sağlık durumlarını izlemekte ve Orchestrator platform event lar oluşturmaktadır. Bu iki yöntem dışında herhangi bir yüksek erişilebilirlik seçeneği sunulmamaktadır.
Orchestrator Database: Orchestrator veritabanı Microsoft SQL Server 2008 ya da 2012 üzerinde çalıştırılmaktadır. Veritabanı, içerisinde tüm runbook ları, log kayıtlarını ve konfigürasyon bilgilerini barındırmaktadır. Yüksek erişilebilirlik senaryolarında cluster yapıda ki SQL Server lar üzerinde çalıştırılması tavsiye edilmektedir.
Runbook Designer: Düşündüğümüz tüm otomasyon işlemlerinin tasarımını, testini yapmamızı ve yönetmemizi sağlayan arabirimdir. Windows explorer da ki ağaç yapısına benzeyen sol taraf ile bulunan runbook larımızı istediğimiz gibi kategorileyip saklayabiliriz. Sağ bölümde ise Microsoft ya da üçüncü parti bir firma tarafında sağlanan Integration Pack leri görebiliriz. Orta bölümde ise düşündüğümüz akışı tasarlayabiliriz.
Runbook Tester: Tasarladığımız iş akışlarının gerçek ortamda çalıştırmadan önce test edebildiğimiz ya da problem yaşadığımız runbook lar için troubleshooting yapabileceğimiz ortamdır.
Orchestration Console: Orchstrator veritabanın da bulunan tüm runbook ların görülüp, başlatıp/durdurulabileceği, gerçek zamanlı olarak runbook ların durumlarının görülebileceği ya da yönetilebileceği bir araçtır. Ayrıca bu araca web arayüzünden de ulaşılabilmektedir. Web üzerinden konsola ulaşabilmek için bağlanılan sistemde Silverlight kurulu olmalıdır. Konsol üzerinden herhangi bir runbook çalıştırmak istediğimizde eğer runbook içerisinde veri girişi gerekiyor ise karşımıza veri girişi yapabileceğimiz bir ekran çıkacaktır. Konsol üzerinde IIS hizmeti çalıştıran bir sunucu üzerine kurulabilir. Eğer konsol için bir yedeklilik isteniyor ise load balancing ayarlaması yapılmış birden fazla IIS çalıştıran sunucu üzerine kurulum yapılabilir.
Orchestrator Web Service: Dış uygulamaların Orchestrator ile bağlantı kurabilmesini sağlayan hizmettir. Aynı zamanda runbook altyapsının diğer portaller ve araçlar üzerinden kullanabilmeyi sağlamaktadır. Benzer şekilde Orchestrator Web Service de üzerinde IIS hizmeti çalışan bir sunucuya kurulmak zorundadır. Yüksek erişilebilirlik yapıları için load balancer arkasında çalışan sunucular üzerinde yapılandırılarak yedeklilik sağlanabilir.
Deployment Manager: Orchestrator içerisinde kullanılmak istenen Integration Packs (IPs) leri sisteme almak için kullanılan arabirimdir.
Genel olarak Orchestrator altyapısının şeması aşağıda ki gibidir,
Yukarıda ki şemaya bakıldığında ortamda ki en kritik bileşenin Orchestrator veritabanının bulunduğu SQL server sunucusu olduğu görülecektir. Yüksek erişilebilirlik ortamlarında SQL Server yapısının da failover cluster yapıda olması tavsiye edilmektedir. Yine şemada görüleceği üzere Runbook Server larında birden fazla olarak düşünüldüğü ve Runbook Server tarafında yüksek erişilebilirliğin sağlandığı görülmektedir.
Peki Orchestrator kurulumlarında tercih edilebilecek yapılar standart olarak nasıldır? Burada da üç ana başlık karşımıza çıkmakta. Bunlar,
Ardından Failover Cluster Manager konsolunda cluster adımızı seçelim ve sol tarafta ki ağaç yapısından Storage–> Disks bölümüne geçelim. Burada Actions bölümünden Add Disk linkine tıklayalım ve açılan menüde karşımıza disk geleçektir. Buradan diski seçip Ok dediğimizde artık Disks altında eklemiş olduğumuz diski Available Storage olarak göreceğiz.
Diski Available Storage olarak gördüğümüzde artık Quorum diski olarak atayabiliriz. Yine Failover Cluster Manager konsolumuzda cluster ismimize tıklayalım ve sağ tarafta bulunan Actions menüsünden More Actions–> Configure Cluster Quorum Settings… seçeneğine tıklayalım.
Açılan menü de karşılama ekranını geçelim ve karşımıza gelen bölümde “Select the quorum witness” seçeneğini seçelim ve Next diyerek ilerleyelim.
Karşımıza gelen “Select Quorum Wİtness” ekranında “Configure a disk witness” seçeneğini seçelim ve Next diyerek ilerleyelim.
Karşımıza gelen ekranda mevcut quorum diskimizi ve az önce Available Storage olarak gözüken diskimizi göreceğiz.
Burada varolan disk yerine quorum konfigurasyonunu taşıyacağımız diski seçelim,
Next diyerek ilerlediğimizde bizden onay istenecektir. Değişikliği onayladığımızda cluster yapımızın quorum konfigurasyonu yeni diske aktarılacaktır ve eski disk Available Storage olarak Failover Cluster Manager konsolunun Disks bölümünde görüntülenecektir.
