Bundan bir kaç gün SRM ile Recovery Planlarını Test ederken bazı sıkıntılar yüzünden testi iptal etmek zorunda kaldım tam bu esnada SRM servisinin durması üzerine garip bir sorunla karşılaştım. SRM servisi durunca vCenter’ın tuttuğu Recovery tasklerinin state’i ile SRM’in stateleri tutmadığından dolayı aşağıda ki ekran görüntüsünde ki gibi bir durum oluştu.
Bildiğiniz üzere VMWare kısa bir zaman önce birçok ürününde köklü değişikliklere gitti ve otomasyon ve yönetim üzerine olan ürünlerini vRealize ailesi altında topladı. Automation Center 6.1’e kadar vCloud adı altında yayınlanırken 6.2 ile artık vRealize Automation Center olarak devam edecektir. 6.1’den 6.2’e geçerken sadece yeni bir isimle değil aynı zamanda bir çok yeni özelliklerde geldi. Bu özelliklerin tüm listesine şuradan ulaşabilirsiniz.
Bu yazımda 6.1’den 6.2’e geçiş adımlarından ve yaşadığım bazı sorunlardan bahsedeceğim. Birkaç ipucu sayesinde bu geçişin sizin için mümkün olduğu kadar kolay olacağını ümit ediyorum.
Bu yazımda, başıma yeni gelmiş bir güncelleme probleminden bahsetmek istiyorum. vCenter’ınızı 5.1’den 5.5’e güncellediğiniz zaman beraberinde SRM’in sürümünü de güncellemeniz gerekmektedir. Aslında oldukça basit ve tek düze olan SRM güncelleme işlemi maalesef vCenter’ın mimarisinde köklü değişikliklerin oluşmasından dolayı bazı sorunlar doğurmaktadır.
vRealize Automation ortamında bazı kullanıcılar sahip oldukları VM’lerin kaynaklarını değiştirmek istediklerinde hata aldıklarına dair bildirimde bulundular . Yapılan işlemler VM’in CPU, memory kaynaklarını değiştirmek veya yeni bir disk eklemek gibi temel işlemler. VM’in Blueprintten ilk talebi esnasında kaynakları değiştirdiğimiz zamansa böyle bir sorun gözükmemektedir. İlk tepki olarak log dosyalarını ve DEM,DEO servislerinin çalışıp çalışmadığını kontrol etmek oldu, bunlarda da bir sorun olmadığını görünce request esnasında oluşan hatayı Google’da aratınca başka kişilerinde aynı sorunla karşılaştığını gördüm.
Hata:
Exception during request callback with id <işlem numarası>. Error Message: [Error code: 42000 ] - [Error Msg: Infrastructure service provider error]
Hepimiz alt yapımızda sorunlar yaşamaktayızdır. Bazı sorunları fark eder bazılarını da tesadüfen keşfetmezsek varlığından bile haberdar olmadan yaşamımıza devam ederiz. Sorun yaşamak, bir IT operasyonunun olmazsa olmazıdır; bu gerçekle yüzleşmemiz gerekli ama bu demek değildir ki tamamen çaresiz değiliz. Sistemlerin yarattığı logları toplamamız, depolamamız ve analiz etmemiz problem anında çözüm süresini azaltmakta ve birçok sorunu oluşmadan önleyici tedbirler alabilmemizi sağlamaktadır.
Baktığımız zaman yıllardır OS seviyesinde log yönetimi yapmaktayızdır. Bir Linux sistem yöneticisinin sorun anında baktığı ilk yer syslog dosyasıdır ortamları büyüdükçe Graylog gibi opensource bir çözüme gidebileceği gibi Splunk veya loggly gibi bir bulut çözümüne de yönelebilirler. Bu ürünleri sanallaştırma yapımızın loglarını analiz etmek için kullanabilsek bile topladığı loglardan hangilerinin önemli olduğunu veya hangi soruna işaret ettiğini out-of-box olarak bilemez.