Bulut ve Sanallaştırma

Bloguma hoş geldiniz umarım benim yazarken keyif aldığım kadar sizde okurken alırsınız.  Burada başlıca bulut bilişim ve sanallaştırma üzerine tecrübelerimi paylaşacağım.

Chef Yardımıyla LAMP Kurulumu

Daha önce bir yazımda Configuration management aracı olarak Chef’den bahsetmiş ve kurulumunu gerçekleştirmiştik. Bu yazıdaysa Chef yardımıyla bir node’a üzerinde LAMP stack oluşturma sürecinden bahsedeceğim.

Bu yazıda daha önce kurduğum Chef server’ın yanında üzerine LAMP rolünü de yükleyeceğim bir adet de Ubuntu 14.04 oluşturdum. Her iki sunucunun hostname’lerini hosts dosyası içerisine yazdım ve FQDN üzerinden bir birlerini pingleyebilmelerini sağladım. Rol,Node ve Cookbook kavramlarından bahsetmiştik. Bunları yönetebilmek için Chef bize knife isimli araç sunmaktadır.

Continue reading

Share on LinkedInTweet about this on TwitterShare on FacebookShare on StumbleUponDigg this

vRealize Automatin Custom VM Name

Her kurumun sunucuları için kullandığı bir isim standardı vardır, bu standart sayesinde sistem yöneticileri sunucuların lokasyonunu, kullanım amacını ve önemini bir seferde görebilirler. vRealize Automation sunuculara bizim belirlediğimiz prefix’leri atasa da son kısmına eşsiz olması için bir sayı atamaktadır. Bu birçok kurumun isimlendirme yapısına uymamaktadır. Bu sebepten dolayı bu yazımda vRealize Automation üzerinden VM talebi esnasında VM adını nasıl belirleyebileceğimizden bahsedeceğim.

Continue reading

Share on LinkedInTweet about this on TwitterShare on FacebookShare on StumbleUponDigg this

Azure Availability Set ve Affinity Group

Azure konusunda sıkça aldığım sorulardan biri de Affinity Group ve Availability Set arasında ki farkın ne olduğu ve neden kullanıldıklarıdır. Eğer Azure veri merkezlerini gösteren video ve fotoğraflara baktıysanız yan yana bir sürü konteyner içerisinde fiziksel sunucuların olduğunu göreceksinizdir. Peki, bir VM yarattığımız zaman bu VM nerede yaratılıyor ve en önemlisi bir biriyle ilişkisi olan VM’leri nasıl yerleştirdiğidir.Bu bilgi bizim mantıksal tasarımı yaparken performans ve SLA değerlerini nasıl tutturacağımızı belirler.

İki farklı senaryo karşımıza çıkmaktadır. İlki VM’lerin mümkün olduğunca bir birine yakın veya aynı fiziksel katman üzerinde tutulması; ikincisiyse VM’lerin mümkün olduğu kadar birbirinden farklı fiziksel katmanlarda bulunmasını isteyebiliriz.

Continue reading

Share on LinkedInTweet about this on TwitterShare on FacebookShare on StumbleUponDigg this

vRealize Automation Error code: 42000

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]

Continue reading

Share on LinkedInTweet about this on TwitterShare on FacebookShare on StumbleUponDigg this

vRealize Log Insight

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.

Continue reading

Share on LinkedInTweet about this on TwitterShare on FacebookShare on StumbleUponDigg this