Konfigürasyon yönetimi ve modern CMDB gereksinimleri

Bu makalede, Yapılandırma yönetimi veritabanlarının (CMDB) oluşturulması ve işletilmesiyle ilgili gerçek sorunları ele alacağız ve bunları çözmenin en umut verici yollarını göstereceğiz.

Ayrıca CMDB kullanarak konfigürasyon yönetimi hakkında konuşacağız ve varlık yönetimi hakkında konuşmayacağız, ancak çoğu zaman bu kavramlar birbirinden ayrılmamaktadır.

CMDB ve konfigürasyon yönetimi

CMDB, Konfigürasyon Yönetiminin temel unsurlarından biridir ve başlangıçta hizmetler, muhasebeleştirilmiş konfigürasyon öğeleri ve bu öğeler arasındaki ilişkiler hakkında bilgi içeren bir veritabanı olarak düşünülmüştür.

Başarılı bir şekilde oluşturulduğunda ve düzenli olarak kullanıldığında CMDB, ITIL’de belirtilen hedeflere ulaşılmasına yardımcı olur:

• bir kuruluş içindeki tüm konfigürasyonların kontrol edilmesi;
• hizmet yönetimi süreçlerini desteklemek için doğru yapılandırma bilgilerinin sağlanması;
• olay, sorun, değişiklik ve sürüm yönetimi süreçleri için bilgi sağlanması;

Bununla birlikte, bir CMDB olağan anlamda bir veritabanı değildir. Çoğu zaman tek bir modelde birleĢtirilmiĢ veya hiç bir Ģekilde birleĢtirilmemiĢ bir dizi ayrı depodan bahsetmek daha doğrudur.

Genellikle durum aşağıdaki gibi görünür:

• yazılım tek bir bilgi sistemi içinde yönetilir;
• yazılım lisansları başka bir bilgi sistemi içinde yönetilir;
• fiziksel sunucular, iş istasyonları, ağ ve diğer ekipmanlar üçüncü bir şirket bünyesinde yönetilir;
• bulut altyapısı nesneleri – başka bir sistemde.

Bu tür sistemlerdeki veriler çoğunlukla yerel yönetim için uygun olan farklı biçimlerde sunulur. Bu durumda, bilgileri merkezi yönetim için uygun olan tek bir veri formatına indirgemek ya mümkün değildir ya da önemli işçilik maliyetleri gerektirir.

Yönetim süreçlerinin kalitesi, bilginin uygunluğuna son derece bağlıdır.

Kuruluş küçük olduğu sürece, varlıklarımız ve konfigürasyonlarımız hakkında güncel bilgileri canlı olarak yayınlama olanağına sahibiz. Ancak bir noktada, kuruluş anında yönetimi “aşar” ve güncel yapılandırma bilgilerinin düzenli bir şekilde depolanmasına ihtiyaç duyulur.

CMDB’de Veri Güncelleme Zorlukları

BT sektörü son 10 yılda oldukça değişti. Proje yönetimine yönelik çevik yaklaşımlar sayesinde BT’den iş değeri elde etme hızı (Time To Value) birkaç kat arttı. DevOps uygulamalarının hayata geçirilmesi, kodun üretken ortamlara eskisinden 200 kata kadar daha hızlı ulaştırılmasını sağlayabilir.

“Kağıt üzerinde” veya Excel’de yönetilebilen statik altyapılar yerini dinamik altyapılara bırakıyor. Sanallaştırma ve bulutlar hayatımıza girmiştir: geçici ihtiyaçlar için konuşlandırılan sanal sunucular, bir fiziksel ana bilgisayardan diğerine taşınan sanal bileşenler ve altyapıda sürekli olarak gerçekleşen bir dizi başka değişiklik. Sürekli güncellenen, geri alınan ve iyileştirilen çok büyük miktarda yazılım var.

Güncel bilgilere erişebilmenizi sağlamak için bu değişikliklerin her birinin izlenmesi ve kaydedilmesi gerekir

Bu tür koĢullarda CMDB “nin temel sorunu içerdiği bilgilerin güncellenmesinin karmaĢıklığı haline gelir.

Bu sorunlar CMDB fikrinin “demir kaplı” yapılandırma birimlerinin hakim olduğu bir çağda oluşmasından kaynaklanmaktadır. Etkili bir yönetim için, her bir unsurun hangi görevleri yerine getirdiğine dair açıklamalar içeren bir altyapı unsurları listesi yeterliydi.

Bu fikir, modern standartlara göre oldukça mütevazı altyapı hacimleri için geçerliydi.

Günümüzde büyük kuruluşların altyapıları sadece binlerce konfigürasyon biriminden oluşmakla kalmıyor, bu da onları manuel olarak etkili bir şekilde yönetmeyi imkansız hale getiriyor, aynı zamanda hibrit, yani fiziksel konfigürasyon öğelerine ek olarak, yüksek derecede değişim dinamiğine sahip kendi iç ve dış bulut kaynaklarını da içeriyor. Böylesine farklı ve hızla değişen yapılandırma öğeleri veritabanını yönetme görevini çözmek BT yönetimi için büyük bir zorluktur.

Bir CMDB oluşturmak ve yönetmek için yaklaşımlar

Manuel

Bilgilerin CMDB’ye manuel olarak girilmesi bir yandan önemli bir insan zamanı yatırımı gerektirirken, diğer yandan hatalara ve tutarsız verilere yol açar.

Bu yaklaşım, statik altyapıya sahip küçük kuruluşlar için geçerlidir.

Ancak sadece bu kuruluşlar büyük olasılıkla CMDB’lere hiç ihtiyaç duymayanlar arasındadır. Modern Ģirketler için bu seçenek kesinlikle uygun değildir. Otomasyon araçlarını kullanmak mantıklı görünüyor.

Keşif

Discovery, altyapı verilerini otomatik bir modda toplamanızı sağlayan özel bir yazılımdır. Discovery motoru, kurumsal ağa bağlı cihazları adreslemek için bileşenler içerir. Ağ, çeşitli protokoller kullanarak ekipmana talepler gönderir, ekipman talebe kimlik bilgileriyle yanıt verir ve böylece CMDB otomatik olarak oluşturulur.

Discovery aşağıdaki görevleri otomatikleştirir:

• yeni CI’ları tanımlar ve bunları CMDB’ye ekler;
• yapılandırma verilerini günceller;
• yapılandırmaların sürümlendirilmesini sağlar;
• Hizmetlerle karşılıklı ilişkilere dair veriler girildiğinde tam teşekküllü bir kaynak-hizmet modeline dönüşen bir altyapı unsurları haritası oluşturur.

Yarı otomatik yaklaşım

Discovery CMDB yazılımı mevcut altyapı hakkındaki verileri otomatik olarak toplar. Eksik veriler ve unsurlar arasındaki ilişkiler daha sonra manuel olarak girilir.

Modern altyapılar dinamiktir, sürekli değişirler, buna göre CMDB’yi güncel tutmak için diskaveraj düzenli olmalıdır ve geniş bir altyapı ile bu hızlı bir süreç değildir. Mantıklı çözüm, keşif işlemini mesai saatleri dışında gerçekleştirmektir.

Etkili bir şekilde kullanmak için ITSM süreçleriyle yakın entegrasyona ihtiyaç duyar, bu nedenle bu mekanizmanın bir ITSM çözümünün parçası olması muhtemeldir. Ve çalışma saatleri içinde başlatılırsa, sistem performansının düşmesi muhtemeldir ki bu kabul edilemez.

Gece bir diskaveraging gerçekleştiğinde ve sabah geliştiriciler örneğin test amacıyla düzinelerce sanal makine dağıttığında mümkündür. Bu anda, bellek yetersizliği nedeniyle, bu sanal makinelerin bulunduğu fiziksel ana bilgisayarda bir olay meydana gelir. Olay çözümleme sürecinde kaynak-hizmet modeline dönüyoruz ve nedenlerini göremiyoruz, çünkü CMDB’miz henüz bu sanal makineler hakkında bilgi sahibi değil ve bir sonraki diskover birkaç saat içinde gerçekleşecek. Ancak bu işlem başladığında, bu sanal sunucuların işlevlerini yerine getirdikleri ve artık ihtiyaç duyulmadıkları için artık var olmamaları oldukça olasıdır.

Böylece diskaveraging’in CMDB’deki veri uygunluğu sorununu her zaman çözmediği sonucuna varıyoruz.

IaC – Kod Olarak Altyapı

DevOps uygulayıcıları bize altyapı yönetimi için yeni olanaklar sundu.

Yazılım tanımlı altyapı, çoktan gelmiş olan bir gelecektir.

IaC’nin özü, eksiksiz yapılandırmaların, kod olarak depolanan bu ayarlarla komut dosyaları kullanılarak dağıtılan kapsayıcılara paketlenmesidir. Artık sunucuları manuel olarak yapılandırmaya veya hatta mevcut olanları klonlamaya gerek yoktur, çünkü bir yönetici bu tür yüzlerce sunucuyu aynı anda koruyabilir.

Konfigürasyonlar CMDB’de kod şeklinde saklanır ve ayrıca kod kullanılarak yönetilir. Ve kod olduğu için insan müdahalesi olmadan test edilebilir. IaC ile sunucuya gidip tüm kütüphanelerin yüklü olup olmadığını, tüm konektörlerin açık olup olmadığını, tüm yapılandırmanın ihtiyaçlarımızı karşılayıp karşılamadığını vb. kontrol etmemize gerek yoktur. Bunun yerine otomatik bir test yazılır. Test başarısız olursa, dağıtılan altyapı iki tıklamayla kaldırılır ve yeni bir dağıtım betiği başlatılır.

Kod olarak oluşturulmuş altyapı yönetim süreçleriyle, dağıtılan altyapı verileri her zaman güncel olacaktır.

IaC ile CMDB, altyapı verilerinin bir toplayıcısı olmaktan ziyade referans altyapı verilerinin bir kaynağı haline gelir.

Önceden bir yapılandırma öğesini keşfetmemiz, tanımamız ve onunla ilgili bilgileri CMDB’ye işlememiz gerekiyordu. Altyapı yönetiminin kod olarak kullanılmasıyla durum tam tersine döndü: önce yapılandırma öğesinin bir modelini oluşturuyor ve ardından gerektiği kadar gerekli yapılandırma birimi oluşturuyoruz.

Otomatik keşif ve kod olarak altyapı yönetiminin birleşiminden bir ideal doğar: sürekli CMDB oluşturma.

CMDB oluşturmaya sürekli yaklaşım

Sürekli keşif, referans bilgi kaynağı olarak IaC ve her zaman güncel yapılandırma ve bazı yönlerden manuel yönetim (maalesef onsuz yapamazsınız, ancak gerekli minimum işlem miktarı olması önemlidir).

Bu üç bileşen bir araya geldiğinde, güncel verilere sahip bir CMDB elde ederiz. Ve güncel bir CMDB BT yönetiminde güçlü bir araçtır.

Bir CMDB nasıl oluşturulur ve yönetilir?

• Bulutta bulunan her şey – “kod olarak altyapı” yaklaşımıyla yönetilmelidir.
• Fiziksel veri merkezlerinde bulunan yapılandırma birimleri – “sürekli keşif” yaklaşımı kullanılarak yönetilir.
• Ofis altyapı unsurları sürekli keşif kullanılarak ve manuel olarak yönetilebilir.

CMDB’ler değişmelidir. Bunların oluşturulmasına yönelik yaklaşımlar değişmelidir. Günümüzde CMDB’ler yalnızca muhasebeleştirilmiş altyapı unsurları ve bunlar arasındaki bağlantılar hakkında veri depolamakla kalmamalı, aynı zamanda hipervizörler, orkestratörler, dinamik yapılandırma yönetim sistemleri ile sıkı bir şekilde entegre olmalıdır.

Aynı zamanda CMDB “lerle yapılan iĢlemler konfigürasyon yönetimiyle ilgili süreçlere doğru ve uygun bir Ģekilde entegre edilmelidir. CMDB’ler esnek ve dinamik hale gelmeli, sorun kaynağı olmak yerine nesnel değer üretmelidir.

SimpleOne SACM

ITSM çözümlerinin SimpleOne platformunda geliştirilmesine yönelik yol haritası, CMDB verilerinin doldurulması ve güncellenmesine yönelik yukarıdaki yaklaşımların tümünü içermektedir. SimpleOne SACM (Service Asset and Configuration Management) yakında yapılandırma ve varlık yönetimi için esnek, kullanışlı ve verimli araçlar sağlayacaktır.

SimpleOne SACM’nin kapsamlı iş çözümü şu modülleri içerecektir:

• SimpleOne CMDB – Sürekli keşif araçları, kod olarak altyapı (IaC) yönetimini düzenlemek için gerekli bileşenler ve kuruluşun kaynak-hizmet modelini oluşturmak ve yönetmek için araçlar içeren CMDB modülü;
• SimpleOne ITAM – BT Varlık Yönetimi Modülü