şükela:  tümü | bugün
  • vmwarein cd den boot edilip işletim sistemi olarak kurulan laboratuvar ı.
    lab. diyorum çünki aşmış bir olaydır kendisi. birbirinden bağımsız osları çatır çutur çalıştırıyor ve aşmış bir yönetim konsolu var.
  • pek muhterem bir arkadaşımla nihayet kurup deneme fırsatına eriştiğimiz ve hemen ardından ağlaya ağlaya silmek zorunda kaldığımız os.

    aslında tamamen ve sadece modifiye edilmiş bir redhat 7.2 sürümünden ibarettir. üzerinde biraz sistemle bütünleştirilmiş bir gsx server* kurulu.

    şu anda minimum 500 dolara toplanabilen minimum sistem konfigürasyonu ise:

    1-2 cpu (min. 900mhz intel xeon veya eşleniği)
    512mb ram
    scsi hard disk (bu şart)
    mümkün mertebe bol disk speysi.

    önerilen durum ise şu:

    16-64 arası işlemci adedi
    64gb - 4tb arası memory
    çılgın atan scsi(tercih: fibre channel) disk(ler)..

    sonuç:
    netten indirilen her beleş program çat diye evdeki pc ye kurmak için değildir.
    vmware gsx server biraz optimize edilmiş bir redhat 7.2 ye kurularak da aynı iş görülebilir.

    (bkz: allah muhafaza)
    not: fibre channel disk dedikleri de nedir mnakoyim?
  • (bkz: fibre channel)
  • diyelim ki 8 cpu'lu 16gb ram'li bir server'iniz var, bu server uzerinde 10 adet 300gb'lik scsi diskimiz var.

    esx'i direkt olarak donanim uzerine kurup arkasindan kendisi uzerine kuracagimiz isletim sistemine, "bak aslinda sen tek cpu'lu, tek diski olan bir server'sin" diyebiliyoruz,

    bu isin en abzurt boyutu ise "aslinda sen 4 tane 2 cpu'lu, 4 gb ram'li server'dan olusan bir distributed yapisin, 4 sucunun her biri ayni datayi tutan farkli db server" dediginiz zaman anlik snapshot'lar yordami ile tek "database"'i 4 makinada (vefakat tek makinada) tutabiliyor.

    "peki psikopat miyim ben, niye tek makinayi dorde boluyorum" derseniz;

    14 sunuculuk bir blade serisi hazirlayip arkasindan san ustunden fibre channel ile birbiriyle konusan san + mainframe mimarisini yakaladigimizda 4 tane blade'i application server, 1 blade'i dc, 2 blade'i firewall, 1 blade'i storage, 6 blade'i de db server olarak atayip (san ustunden esx server calistirip data'yi ornegin bir ds4300 ustunde tutup donanimi da blade'lerimizden aliyoruz, 4 sunucuyu tek makina gibi gosterip bir i$e, 2 sunucuyu tek makina gibi gosterip diger bir i$e atiyoruz) guzel bir server farm olusturuyoruz kendimize.

    e peki bunun guzelligi nerede?

    su 6 blade db'ye fazla oldu, dc'ye tek blade yetmiyordu, dur db'deki 6 blade'den birini firewall'a aktarayim ortam rahatlasin, bosuna donanim gucu harcamayayim gibi manevralara imkan taniyor bu mimari. direk sistem calisirken donanim yonendirmesi yapabilmek, donanim bazli sorunlarda, kaynak yetersizligi durumlarinda sistemi up tutarak her turlu operasyonu yapabilme yetisi sagliyor.

    adamlar gercekten cok guzel bir is basarmislar. (her ne kadar anlatmayi beceremesem de)
  • kurulum sirasinda yeteri kadar swap space ayarlamadiginiz zaman patlayabilen sistem. ornegin, 1.5 gb swap space'iniz varken 300 gb virtual server kurmayin. *
  • bu urun ile ilgili garip bir sorun mevcut.

    yazilimi kullananlar genellikle multiprocessor mainframe'leri shared hardware olarak kullanmak isteyenler.

    yazilim cpu based license istiyor. bu durumda bir x system 3950 aldiginizda 8 cpu icin esx'e 40000$ oduyosunuz; donuyorsunuz her kurdugunuz windows server icin ayrica cpu license oduyorsunuz. utanmadan sql falan kurarsaniz ona da oduyorsunuz.

    bu durumda esx size oluyor 40000$'lik kulfet.(consolidated backup'i vs'yi dahil etmeden.

    8 cpu'lu bir x system 3950 yaklasik $80000'e mal oluyor. (ram + storage ile)
    40000$'da esx icin ekledigimizde 120000$.

    buradan bakildiginda esx ile bolmek yerine (ibm ile basladik ibm ile gidelim) x346 ile devam ettiginizde 2 cpu 8 gb ram'li bir x346'yi uzerinde 5 adet 10k rpm 72'lik scsi disk ile ~$5000'e mal edebiliyorsunuz.

    24 tane x346 alinabiliyor bu paraya 10 tane almaniz durumunda hem licence'lar da dahil projeyi kotarmis olursunuz hem de dagitik bir server yapisina sahip olursunuz. istediginiz gibi share edebilirsiniz.

    tabii arada esx'in application server'lar icin sundugu single execution gibi bir mantik var ama durum boyle bakilinca muthis karisik ve komplike bir hal aliyor.

    icinden cikabilirsem sonuca baglarim donup diyor; bu degerlendirmeyi de burada sonlandiriyorum.
  • (bkz: vmotion)
  • versiyon olarak 3.5'in update 2'sini yükleyenlerde 2 gün önce büyük bir bug ortaya çıkmış ve kapatılan virtual machine'ler bir daha açılamaz olmuşlardır. ayrıca vmotion gibi bazı özellikleri de kullanılamaz duruma gelmiştir. vmware yaptığı bir açıklamayla sistem saatlerini geçici olarak geri alarak bu problemin giderilebileceğini söylemiş. bu devirde böyle iyi bir firmadan bunu duyduğuma açıkcası çok şaşırdım. bir dolu enterprise seviyede kuruluşun bu ürünü kullandığını düşünürsek online sistemlerin saatini geri almanın pek uygun bir çözüm olmadığı çok açık. heralde panikten ne diyeceklerini şaşırdılar. böyle kritik bir hatayı tespit etmeden kullanıcılara dağıtılmasını onaylayan kalite departmanına da selamlarımı gönderiyorum. neyse ki gerekli düzeltmeyi dün yaptılar ve update 2'nin düzgün halini piyasaya sürdüler.
  • misyon kritik uygulamalar için vm teknolojisinin ne kadar hayati öneme sahip olduğunu anlayabilmek için çok miktarda box'ın (sunucu ve disk sistemleri) bir arada olduğu ve bunların üzerinde çok sayıda farklı uygulamanın çalıştırıldığı büyük bir yapıdaki işlevinin görülmesi gereken çözüm.

    bir sunucu düşünün, ne basidinden üzerinde web sunucu olsun. bu web sunucu üzerinden satış yaparak para kazandığınızı düşünün. bu sunucunun erişilemediği her saniye sizin için bir kayıp olsun. bu durumda bu sistemin her an her saniye (7/24/365 ve hatta o kıyrıtık 6 saat) erişilebilir olmasını isteyeceksiniz. -- konu bu noktaya gelmişken hemen ilk ve yetkin ağızdan şunu söyleyeyim: dünyada hiçbir sistemde %100 availability'den bahsedilemez. (bkz: availability) (bkz: high availability). en erişilebilir olan sistemler 5 9'luk (99,999) veya daha da abartılı bir yapıysa 6 9'luk (99,9999) erişilebilirlik sunarlar. --

    bu senaryoda örneğin sunucunun donanım bakımının yapılması gerektiğinde, sunucu esx server üzerindeyse ve birden çok donanımınız varsa, web sunucunuzu hiç kapatmaksızın bir başka donanıma aktarabiliyor, erişilebilirliğinizden hiçbirşey kaybetmiyorsunuz. müşteriler memnun, siz memnun..

    tabii bu sadece bir özelliği.

    tanımladığınız her sunucunun "sanal" olduğunu bir kez daha vurgulamak gerek.. sanal olmasının getirdiği birçok avantaj var. disk kapasiteyi az gelen vm'e (virtual machine = sanal makine) istediğiniz an disk ekleyebilir, cpu veya memroy artırımı yapabilir, veya azaltabilirsiniz.

    istediğiniz vm'in istediğiniz an bir snapshot'ını alabilir, yedekleyebilir, istediğiniz vm'i klonlayabilirsiniz.

    istediğiniz kurulumu, automated hale getirebilir, gerektiğinde saniyeler seviyesinde yeni vm kurulumu yapabilirsiniz.

    istediğiniz vm'e oturduğunuz yerden power off / power on / reset gibi işlemler yapabilir. yerinizden kalkmadan, vm inizin konsoluna erişirsiniz. (server odası görmüş olanlar bilirler, bir makianaya erişemediğinizde, genelde klimalarla 15-17 dereceye düşürülmüş havanın oldugu odaya girip sorunlu makınayı baştan başlatmak, kontrollerını yapmak ıcın o sogukta belkide saatlerce başında beklemek, konsolunden giriş yapabilmek için de yıne o odada bulunmak gereklidir)

    virtualization (sanallaştırma) teknolojileri, sunucular dünyasında çok önemli bir misyona sahiptir. bunu anlamak için bu girdide yazdıklarımı ucundan köşesinden anlamak yeterlidir.
hesabın var mı? giriş yap